<tony_>
naobsd, google have some problem for me now. Is there other way to send to you ?
<naobsd>
mmm
<naobsd>
how large is it?
<tony_>
2M
<tony_>
2M bit.
<tony_>
2M Byte. ;P
<naobsd>
I guess email is ok, please send it to naobsd@gmail.com
<naobsd>
unless "google problem" doesn't prevent email too ;)
<naobsd>
tony_: thank you!
<tony_>
naobsd, just today. I can use google sweet before. ;P
<tony_>
naobsd, for now, I'm confused about the PAD SDK with HDMI.
<tony_>
naobsd, when I connect it to TV by HDMI and the TV say the input source is 1080P.
<naobsd>
tony_: can I share that patch if someone want it?
<tony_>
naobsd, there is no problem about patch. ;P
<naobsd>
tony_: fb resolution (number of x/y pixels) and HDMI signal is independent
<naobsd>
tony_: if fb resolution and HDMI signal isn't match, content is scaled
<tony_>
naobsd, but there is warnnings about it. It can not be updated by OTA, so you can just you it in a new project.
<naobsd>
tony_: thank you for patch! ah no problem, I just refer them for bootloader related work
<naobsd>
tony_: are you using rk61x for LVDS/HDMI?
<tony_>
rk616.
<naobsd>
if my memory is correct, fb resolution is same as LCD pixels, and picture is scaled on HDMI
<naobsd>
I guess you can set fb resolution 1920x1080 and scaled for LCD, but sorry, I have no idea for now
<naobsd>
I have 1024x600 screen for RR, I want to try it too
<tony_>
naobsd, I guess so. thank you for giving me direction. ;P
<Shinde>
"console=ttyFIQ0 androidboot.console=ttyFIQ0" in dmesg implies the UART serial should be enabled?
<naobsd>
Shinde: it just tells "ttyFIQ0 is console". you can set it even if UART is not enabled.
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 246 seconds]
<Shinde>
Is there and easy way to determine where the UART pins are, so I can check? I have this little crap 50$ tablet using rk3126 and was looking at the viability of putting a proper Linux on it.
<naobsd>
Shinde: I'm not sure what "proper Linux" is. about UART pins, I think you need to see & check the board
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
<Shinde>
Not Android, standard init, userland and so forth.
markm has quit [Ping timeout: 246 seconds]
ssvb has joined #linux-rockchip
levd has joined #linux-rockchip
<tony_>
naobsd, I made it. I changed the LCD's resolution to 1920x1080 then the LCD don't work fine, but the HDMI work fine. looks cool.
levd1 has quit [Ping timeout: 260 seconds]
<rperier>
c0d3z3r0: do you have another message ? with mainline ?
JohnDoe_71Rus has joined #linux-rockchip
<naobsd>
tony_: sounds nice :)
<naobsd>
hmmmm
<naobsd>
ENOSPARETIME :(
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 252 seconds]
cristian_c has joined #linux-rockchip
<cristian_c>
tony_: hi
<rperier>
ELC for an hobbyist... 300 $ USD ... ? seriously ? :/
<rperier>
whoo^^
<tony_>
cristian_c, hi
<sjoerd>
naobsd: great thanks :)
<naobsd>
sjoerd: most cases I erased eMMC sector 64 to force USB/SD booting on RK3288
<naobsd>
I heard RK3188 boot priority is "SD then eMMC", I wonder why RK changed it to "eMMC then SD" on RK3288 :(
<sjoerd>
naobsd: right yeah for now i jusr keep hitting my board with tweezer aas i wanted the original loader to stay alive while playing with the upstrema code
rory096 has quit [Ping timeout: 250 seconds]
<sjoerd>
naobsd: RK3188 definately boots SD before nand (i don't have an 3188 with emmc)
<naobsd>
RK's U-boot seems to support SD card(load kernel etc from SD) even if it's booted from eMMC(loader is in eMMC), so it shouldn't be a problem for many people who has interest about only kernel and userland
<cristian_c>
tony_: I've found a method to debug the early boot
<naobsd>
sjoerd: yes "SD then NAND". I also doesn't have RK3188 with eMMC
<sjoerd>
naobsd: yeah it gets rather confused if i put in my SD card with upstream u-boot (which ahs the right header at "IDR 0")
<naobsd>
more accurately I have ASUS Memo Pad 8 which has RK3188 and eMMC, but probably it does SPI boot... I cannot find bootloader in eMMC
<sjoerd>
which was funny to see
<tony_>
cristian_c, what method ?
<cristian_c>
tony_: it's called delay_boot
<cristian_c>
tony_: netconsole and serial console didn't work. Instead delay_boot did the trick
<tony_>
cristian_c, I thought the serial console is high end method to debug early boot. ;)
<tony_>
cristian_c, what you said about early boot is mean u-boot ?
<tony_>
cristian_c, or kernel ?
<cristian_c>
it's needed to enable confog_boot_printk_delay in kernel .cofig and then you have to add delay_boot=number_of_ms plus jpl parameter
<cristian_c>
tony_: serial console didn't work
<cristian_c>
I tried with minicom, but I didn't see anything on the remote pc screen
<cristian_c>
tony_: kernel
<cristian_c>
tony_: with delay boot I've figured out the kernel panic reason
<cristian_c>
and I fixed it
<tony_>
cristian_c, cool
<cristian_c>
it's a slow-motion boot
<tony_>
cristian_c, can you explan how it work ?
<cristian_c>
with printk messages delayed by chosen milliseconda, in my case 200 ms
<sjoerd>
naobsd: and yeah upstream u-boots are often good enough for people just wanting to play a bit, but they make things rather inconvenient for distributions and folks that come accross a lot of different SoCs (how did booting on this one work again, arggh).. Hopefully getting rk3288 support properly upstream will help people a bit :)
<tony_>
cristian_c, but I think this just turn slow the speed.
<tony_>
cristian_c, do you think so ?
<naobsd>
I want to try sjg's u-boot patches for rk3288
<naobsd>
hmm... it seems there is no much free time :(
<tony_>
cristian_c, what you mean is the printk can not work fine on early boot. if you use the config_boot_printk_delay the information should be printed will be printed ?
<cristian_c>
tony_: anyway, boot_delay could be a quick and sure method to solve issues, I'll try that also in rk3188 machine (it boots only with prebuilt kernel. Boot with kernel built bymme fails)
<naobsd>
anyway I have to rebuild my build machine at first :(
<tony_>
cristian_c, I haven't use their kernel. ;)
<cristian_c>
tony_: I had no alternatives :D
<cristian_c>
tony_: with alok kernel many i2c devices were not detected, and backlight was turned off
<tony_>
cristian_c, why can you use the mainline kernel ?
<cristian_c>
because specific configurations are located into .c files in /arch/arm/plat_rk directory
<cristian_c>
tony_: interesting, but does mainline kernel contains hardware specific configurations?
<cristian_c>
as cameras, backlight, gsensor, touchscreen...
<sjoerd>
naobsd: btw, maybe you happen to know, is there a way to determine what device SROM started the first stage loader from ?
<cristian_c>
tony_: enabling specific options in alok kernel .config wasn't enought, bacause they were never used by .c code
<cristian_c>
I mean hotdog_defconfig, that is used by alok kernel
<cristian_c>
(mach_hotdog)
<sjoerd>
cristian_c: On mainline you describe your hardware using device-tree, so there shouldn't be hardware specific configuration in C code
<cristian_c>
sjoerd: I'll try to take a look
<cristian_c>
do you mean linaro kernel as mainline, either linux official github repository?
<sjoerd>
neither, i mean actual git.kernel.org
<cristian_c>
ok
<cristian_c>
tony_: with mach_hotdog and previous kernel, I had no ack messages im dmesg log
<tony_>
cristian_c, by what ?
<tony_>
cristian_c, serial ?
<cristian_c>
now, with particular mach and rkcrewtablet kernel, xorg.0.log registers some devices as input0 (rk29-keypad), input1 (lis3dh gsensor) and input2 (ct36 touch), but only keypad is shown by xinput list output and xev detects keypad buttons pressure (3 of 4 buttons , and they are detrcted wrong, but it setup for another tablet model :P)
<cristian_c>
tony_: no
<cristian_c>
tony_: I talked about hardware support/detection by the os)
<cristian_c>
I'll take a look to mainline kernel, anyway :)
<tony_>
cristian_c, you can make it. ;P
<naobsd>
sjoerd: it should be available, but I need to investigate it
<naobsd>
sjoerd: SPL should be able to know it to load u-boot binary, right?
markm has joined #linux-rockchip
<sjoerd>
naobsd: Yeah but the SPL needs to know where to load it from, the current code in that branch just loads it from what u-boot calls "mmc 0"
<sjoerd>
iotw the SPL will just always load u-boot from the SD card as far as i can tell
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 246 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 256 seconds]
dlezcano has quit [Remote host closed the connection]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 245 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 240 seconds]
dlezcano has joined #linux-rockchip
tony_ has quit [Quit: Leaving]
Shinde has quit [Ping timeout: 244 seconds]
Shinde has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
pietrushnic`away has joined #linux-rockchip
pietrushnic`away is now known as pietrushnic
ssvb has quit [Ping timeout: 252 seconds]
nighty^ has joined #linux-rockchip
cristian_c has quit [Quit: Bye]
Bludot has joined #linux-rockchip
<c0d3z3r0>
mmind00: are there any known issues with regulators at the moment? I can't boot rk3188 with next but works fine with 4.2-rc6
ssvb has joined #linux-rockchip
<mmind00>
c0d3z3r0: not that I know of, any interesting console output
<karlp>
c0d3z3r0: why would the ip outside germany matter?
<karlp>
are you trying to live on the not-internet?
<c0d3z3r0>
karlp: geoblocking ;)
<sjoerd>
c0d3z3r0: fwiw [ 5.142214] vsys: disabling is rather suspicious
<karlp>
c0d3z3r0: so, you're chatting in an international forum, on an international topic, but you only want to work with germans?
<karlp>
I thought only narrow minided american firms took this sort of position, not european individuals.
<c0d3z3r0>
karlp: no, I just forgot, that I should use pastebin here :)
<karlp>
the fact that you think it is a good idea at all is still concerning
<c0d3z3r0>
what is not a good idea? blocking ips from outside to my server?
tonokip2 has joined #linux-rockchip
<mmind00>
c0 yep, in the Netherlands right now :-)
<sjoerd>
c0d3z3r0: looks like i2c troubles: [ 3.827646] rk3x-i2c 2002f000.i2c: timeout, ipd: 0x00, state: 1 -> that's the i2c bus that talks to your pmic
<c0d3z3r0>
mmind00: that explains ;) I should pin a big post-it "pastebin" at my screen :'D
<karlp>
what "protection" is your geoblocking meant to provide?
<c0d3z3r0>
karlp: bots from china, russia etc. there is nothing interesting for others on my server
<karlp>
but bots from germany are ok? goodo.
<c0d3z3r0>
it is a bit of protection so why shouldn't I use it? — I fully agree with you that using my paste site in an international chat isn't a good idea; that really wasn't intended
rory096 has joined #linux-rockchip
rory096 has joined #linux-rockchip
<c0d3z3r0>
mmind00: next-20150814, still working
<mmind00>
c0d3z3r0: wouldn't a git bisect work better to find the offending change?
nighty^ has quit [Ping timeout: 260 seconds]
<c0d3z3r0>
mmind00: yep :D
nighty^ has joined #linux-rockchip
<rperier>
do you know if someone plan to work on camera interface ? (or perhaps that something already exists and will be upstreamable later)
<mmind00>
rperier: no and no I think
<mmind00>
rperier: the chromebooks seem to use usb-connected parts and the Android area uses these strange binary userspace stuff
<c0d3z3r0>
rperier: you said you're using kexec on arm without problems. are you using a smp kernel?
<rperier>
arf, so they don't use rockchip camera interface ... I see, okay I will look at it
<rperier>
I just look at which IP are supported or not (like cif, crypto etc...)
<rperier>
[ 0.000000] DT /cpu 2 nodes greater than max cores 1, capping them"
<c0d3z3r0>
rperier: my cpus 1-3 won't come online… :( yes
<rperier>
(not sure if it is related to your problem... it might be...)
<c0d3z3r0>
I try to kexec an smp kernel from a up kernel
<rperier>
I think that the mainline kernel has regression with old SoCs, which might explain your problem
<rperier>
I can try to boot my marsboard (or my radxa rock) when I back to home, If you want
<c0d3z3r0>
oh wait.. I get the error above only on first boot with the up kernel. after kexec the smp kernel only says "CPU1: failed to come online"
naobsd has quit [Quit: naobsd]
cnxsoft has quit [Quit: cnxsoft]
premoboss has joined #linux-rockchip
rory096 has quit [Ping timeout: 252 seconds]
rory096 has joined #linux-rockchip
rory096 has joined #linux-rockchip
rory096 has quit [Ping timeout: 246 seconds]
rory096 has joined #linux-rockchip
<rperier>
c0d3z3r0: any progress ?
<c0d3z3r0>
still bisecting the i2c / regulator bug
<c0d3z3r0>
2 steps left
<c0d3z3r0>
mmind00, rperier, sjoerd: and here comes the culprit.. 07a06ae99ef9b8eda3ec0b69c8f477856042a511 pinctrl: rockchip: only enable gpio clock when it setting
sunilmohan_ has joined #linux-rockchip
<c0d3z3r0>
mmind00: adding pclk_pd_pmu to the critical clocks for rk3188 like you did for rk3288 solves the problem
<c0d3z3r0>
mmind00: adding pclk_gpio0 also works but I really don't know which is the right one here
<rperier>
feel free to send a patch to the ML :)
<mmind00>
c0d3z3r0: pclk_pd_pmu to critical clocks is the right solution
<c0d3z3r0>
mmind00: I can't find pclk_pd_pmu in any rk3188 related file with grep o.O how does this work? :O
<mmind00>
c0d3z3r0: didn't you write "adding pclk_pd_pmu to the critical clocks for rk3188 like you did for rk3288 solves the problem"? ;-)
<c0d3z3r0>
mmind00: yes, but I don't understand why :'D that was just try'n'error after seeing your rk3288 patch
<mmind00>
interesting :-)
sunilmohan_ has quit [Quit: Leaving]
<c0d3z3r0>
mmind00: pclk_pd_pmu is only in clk-rk3288.c ...
<mmind00>
c0d3z3r0: yes I see that too now
<c0d3z3r0>
I tested again… removing pclk_pd_pmu from rk3188 reveals the problem again
<c0d3z3r0>
it's magic \o/
<mmind00>
that cannot be right ... could you put down the voodoo doll please? ;-)
<c0d3z3r0>
:D
<mmind00>
c0d3z3r0: can you try adding "pclk_cpu" to the critical list?
<mmind00>
oh wait
* mmind00
takes back the "oh wait"
<mmind00>
I was looking at i2c0, realized that the act8846 is connected to i2c1 and then realized that still both are supplied by pclk_cpu
<c0d3z3r0>
I just cleared ccache and my workdir to test again with "pclk_pd_pmu" after that I'll test pclk_cpu
akaizen has quit [Remote host closed the connection]
<c0d3z3r0>
mmind00: pclk_pd_pmu was just a cache issue… not working after complete cleanup
dd5xl has joined #linux-rockchip
<dd5xl>
Hi all!
<c0d3z3r0>
mmind00: pclk_cpu works
premoboss has quit [Remote host closed the connection]
amstan_ is now known as amstan
<c0d3z3r0>
rperier: is there any way to debug the cpu problem?
akaizen has joined #linux-rockchip
<rperier>
not really, at this step very few things are available... I mean no kdb or kgdb... I use say use your uart with printk ?
<rperier>
s/use say/would say/
<rperier>
the strange thing is that... it seems to work on my marsboard (rk3066)...
<rperier>
c0d3z3r0: could you paste your fix somewhere or send a patch on the ML ?
<rperier>
(what I meant is that I have the pmu issue, but cpu issues when using kexec seems to works fine...)
rory096 has quit [Ping timeout: 245 seconds]
<c0d3z3r0>
rperier: I've already sent in my patch
<c0d3z3r0>
"[PATCH] clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks"
<c0d3z3r0>
rperier: could you test kexec with your radxa rock, please? or maybe share your config so I can test it on mine
<dd5xl>
Can anyone please point me to a working Marsboard 3066 defconfig?
<dd5xl>
I can't manage to get the mmc activated, boot stops when the mmcblk0 partitions are to be mounted....