<tony_>
naobsd, after fbset, there will be a tiny desktop UI. ;P
<tony_>
naobsd, and what version kernel you tried ?
<tony_>
naobsd, my kernel version on rk3188 is 3.0.36.
<naobsd>
3.0.36
<tony_>
naobsd, would you tell me what's the LCD on it ?
<naobsd>
what's the problem in that picture?
<tony_>
naobsd, tiny UI.
<naobsd>
I tried only HDMI out on RK3188
<tony_>
naobsd, can not you see a tiny UI on the screen ?
<naobsd>
I can see it
<naobsd>
you changed fb resolution, isn't it?
<tony_>
naobsd, yes, but it works fine on RK3288.
<tony_>
naobsd, I think my direction is right.
<naobsd>
if it works fine, there is no problem
<tony_>
naobsd, but maybe there is a BUG on the rk3188.
<tony_>
naobsd, again: on RK3288 it works fine, but on RK3188 it does not work fine.
<tony_>
naobsd, from that, I think my direction is right, but there maybe some BUG on rk3188 kernel.
<naobsd>
well
<tony_>
naobsd, I check the resource for 5 days, I have not get answer.
<tony_>
naobsd, I check the code for 5 days, I have not get answer.
<naobsd>
you didn't explain about that picture, it that RK3188?
<naobsd>
is that RK3188?
<tony_>
naobsd, the picture is RK3288.
<naobsd>
I see
<naobsd>
btw why do you use fbset?
<tony_>
naobsd, the framebuffer has many func such as fb_set_var/fb_check_caps/fb_pan_display/fb_add_videomode...
<tony_>
naobsd, there just less document about them, I don't know what useful of them.
<naobsd>
why fbset is needed? what do you want to do? evaluating fbset command is your current target?
<tony_>
naobsd, for your question "why do you use fbset", my answer is that like a laptop which resolution can be adjust.
<tony_>
naobsd, why not for rk3188? so I want to adjust resolution.
<naobsd>
LCD panel should have fixed resolution
<tony_>
naobsd, 'cause fbset is right way to adjust resolution.
<naobsd>
"adjust while running"? "adjust at compile time" is common way
<naobsd>
unless if you want to support multiple LCD panels without kernel recompile
<naobsd>
well
<naobsd>
fbset will be one of the way
<naobsd>
it might be "right"
<tony_>
naobsd, Can not your laptop adjust resolution ? which use LVDS LCD too. why it can adjust resolution a same LCD panel ? it is just fb resolution.
<tony_>
naobsd, fb resolution and LCD resolution should be independent.
<naobsd>
are you talking about non-Android product?
<tony_>
naobsd, run "adb shell stop" to stop the android UI, then adjust resolution, then "adb shell start" to restart Android UI.
<naobsd>
I'm very sure that I can change fb resolution on my laptop while running
<tony_>
naobsd, I'm sure talk about Android product.
<sjoerd>
naobsd: btw given you mentioned the rockchip kernel ddr stuff, if i both the vnedor kernels with upstream u-boot everything explodes badly in that code
<sjoerd>
naobsd: haven't looked at what causes it but i suspect the loader stashes some information someplace for it to use
<naobsd>
I think changing fb resolution on Android is not common behavior
<tony_>
naobsd, would you tell me where to save resolution args in kernel framebuffer ?
<naobsd>
sjoerd: well, on RK3288?
<tony_>
naobsd, I think you know the framebuffer driver better than me. ;)
<tony_>
naobsd, Is fb_set_var or fb_add_videomode ?
<naobsd>
tony_: usually it's defined at compile time. lcd_XXX.c has LCD parameters.
<tony_>
naobsd, I meas dynamic arg. such as the resolution you have adjust on radxa.
<sjoerd>
naobsd: on 3288 yeah
<naobsd>
tony_: all Android devices with LCD (I tried) had fixed fb resolution. there is no args.
<naobsd>
sjoerd: well, upstream u-boot can pass vendor dtb when entering vendor kernel?
<naobsd>
tony_: my fbset experience on rk3188 is for Linux environment
<sjoerd>
naobsd: the vendor kernel uses an appeneded dtb
<sjoerd>
naobsd: just disabling the ddr drivers for the vendor kernel maeks things bootable, which is good enough for me
<sjoerd>
this was just a FYI
<sjoerd>
as we were talking about the ddr stuff last week or so
<naobsd>
sjoerd: ah, DDR stuff issue, I see
<sjoerd>
Oh was i unclear, sorry, didn't have my coffee yet :)
<naobsd>
DPLL freq is not same?
<sjoerd>
Yeah i have a sneaky suspicion the binary loader puts some data in ram someplace which the ddr driver in the vendor kerenl can use to do frequncy scaling
<sjoerd>
naobsd: No it's simply a matter of the driver crashing, not the board
<naobsd>
I'm not sure why loader can interfere with kernel
<naobsd>
I guess DPLL freq may be different and it may not be acceptable for DDR stuff in vendor kernel
wb|biketron has quit [Ping timeout: 252 seconds]
<sjoerd>
naobsd: it's the other way around
<naobsd>
ah well
<naobsd>
some DDR information such as row can be get from some
<naobsd>
somewhere outside of DDR controller
<naobsd>
I guess it's given by DDR init blob
<sjoerd>
nod
<naobsd>
I guess vendor kernel try to refer it
<sjoerd>
exactly my suspicion
<naobsd>
there must be some code in ddr.c
<naobsd>
in vendor kernel
<sjoerd>
nod
<naobsd>
mmm
<sjoerd>
Wonder how much power that actually potentially saves though
<naobsd>
my info about DDR is basically for rk30/31, it seems ddr_rk32.c in vendor 3.10 is somehow different...
<sjoerd>
for the use-cases i care about that sutff isn't important anyway (nor do i want to use the vendor kernel, only to test/compare against sometimes)
<naobsd>
hm
<naobsd>
little busy for now...
<naobsd>
tony_: btw your customer really want to change fb resolution while running Android like as laptop?
<tony_>
naobsd, not really, but there are some reason with it. if I can change the fb resolution then the TV(hdmi) and the master screen resolution can be independent. User can get a high resolution on TV though the master screen solution is low.
<tony_>
naobsd, other reason is we can support multi resolution screen at one firmware.
wb|biketron has joined #linux-rockchip
<naobsd>
tony_: now I understand why you want fbset. thanks.
<rperier>
hi all
tony_ has quit [Ping timeout: 244 seconds]
tony_ has joined #linux-rockchip
naobsd has quit [Ping timeout: 250 seconds]
naobsd has joined #linux-rockchip
ssvb has joined #linux-rockchip
nighty^ has joined #linux-rockchip
<rperier>
that's me or kdbus has been completly removed from "next" ?
<rperier>
:/
<sjoerd>
It was clear a while back the current patchset wasn't going to make it in right, so that makes sense
<sjoerd>
(I havne't seen recent updates, but maybe i missed them)
<rperier>
even if it was not technically perfect and a lot of people had revelant remarks, it is too bad to not be able to find a solution for everyone, imho
<sjoerd>
Oh i would expect this story will continue for a while
<sjoerd>
But if the current set isn't expected to go into master it seems sensible to not have it in next, that's all
<rperier>
however, I have not seen recent updates myself or did not follow the subject, but anyway... communication inside a floss project like linux is important
<rperier>
a solution always exists...
<rperier>
lwn.net/kernel is my friend, I will look at it :)
apritzel has joined #linux-rockchip
GekkePrutser_ has joined #linux-rockchip
lerc has quit [Quit: No Ping reply in 180 seconds.]
levd has joined #linux-rockchip
GekkePrutser has quit [Ping timeout: 240 seconds]
GekkePrutser_ is now known as GekkePrutser
lerc has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
tony_ has quit [Remote host closed the connection]
levd1 has joined #linux-rockchip
rk3288_git has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
<rk3288_git>
hi all, does anyone have a correct url for the GIT mirror for the latest r-box_android 5.1 SDK master branch?
<rk3288_git>
I know of: git://git.us.linux-rockchip.org/rk3288_r-box_android4.4.2_sdk.git but what about 5.1?
apritzel has quit [Ping timeout: 264 seconds]
levd1 has quit [Remote host closed the connection]
levd has joined #linux-rockchip
<karlp>
rk3288_git: talk to your device vendor and ask for one.
<mrutland>
mmind00: Thanks to your help I have rkflashtool going, but the boot partition seems to be laid out differntly than older boards, and the DTB seems to be embedded in the stage-2 loader in the android boot img
<mmind00>
mrutland: nice that the flashtool is working ... regarding "partitions", there is often both (kernel + resource and a partition for an android boot image)
ssvb has joined #linux-rockchip
<mmind00>
mrutland: and the bootloader decides which one to load in some sort of fallback scheme
<mmind00>
mrutland: as for the bitmaps I'm not sure ... I did pull that image out of the flash, extracted it and then just put the bitmaps in again ... just to make sure uboot does not choke ;-)
<mrutland>
Ah. It looks like I need to extract thsoe from the stage-2 loader as well then.
<mmind00>
mrutland: although the board I have does not contain a big central pmic, so you might want to look if your board does
<mrutland>
mmind00: Ah, ok. I think I just managed to extract the DTB, and half of logo.bmp. resource_tool doesn't seem too happy
<mmind00>
mrutland: just looked at your board-photos ... didn't find any ic looking like a pmic :-) ... the chips on there look quite similar to what is on my board
<mmind00>
mrutland: don't look to closely at the vendor-dts, it might hurt your eyes
<mrutland>
Yeah, just discovered /tp-fw, which seems to be designed to cause pain
<mrutland>
compatible = "bluetooth-platdata";
<mrutland>
:(
faddat has joined #linux-rockchip
<faddat>
Hi, curious if anyone here knows how to go about building Linux 4.2 for rk3688?
<faddat>
*
<faddat>
3368
<faddat>
"make: *** No rule to make target 'rk3368-r88.img'. Stop" is what we're getting after setting it to use the arm64 architecture...
<faddat>
root@vultr:~/linux-next# make ARCH=arm64 defconfig
<faddat>
HOSTCC scripts/basic/fixdep
<faddat>
SHIPPED scripts/kconfig/zconf.tab.c
<faddat>
HOSTCC scripts/kconfig/conf.o
<faddat>
SHIPPED scripts/kconfig/zconf.lex.c
<faddat>
SHIPPED scripts/kconfig/zconf.hash.c
<faddat>
HOSTCC scripts/kconfig/zconf.tab.o
<faddat>
HOSTLD scripts/kconfig/conf
<faddat>
*** Default configuration is based on 'defconfig'
<faddat>
#
<faddat>
# configuration written to .config
<faddat>
#
<faddat>
root@vultr:~/linux-next# make ARCH=arm64 rk3368-r88.img -j8
<mmind00>
faddat: 4.2 won't help you on the rk3368
<mmind00>
faddat: oh and make sure the flashtool values (from the bpaste link) match the partitions on your device
<faddat>
oh hi mmind! I've been knee deep in your repository!
<faddat>
and thank you for the links! Are the relevant files in your repo?
<faddat>
or should I use the torvalds linux-next?
<mrutland>
faddat: use the arm-soc tree linked to above; linux-next is likely to vary and/or break more
cristian_c has joined #linux-rockchip
<mmind00>
faddat: yep, use the armsoc tree as mrutland said ... there is currently nothing else pending for the rk3368 that would require to use my dev-repo
<mmind00>
faddat: aka the link pointed to the webinterface
<faddat>
100thanks-- I'm kinda new to this :)
<faddat>
did not know to change cgit to /pub/scm
<mmind00>
faddat: in a git-web display, clone-urls are normally shown at the bottom of the main-page
<mrutland>
mmind00: Sorry for yet more noise, but with the instructions you gave for flashing the kernel and resources, did anything else need to be altered (e.g. params), or fiddled with at boot time to get the new kernel, DTB and so on to be used?
<mmind00>
mrutland: no need to be sorry ... does it try to boot your kernel at all, or is it still booting the old one?
<mrutland>
mmind00: It still loads the old kernel and old DTB
<mmind00>
mrutland: hmm, as I said there are often two different boot methods supported
<mrutland>
mmind00: I altered the DTB to have /hello-mark and /chosen/hello-mark nodes, and used the old kernel. Neither node appears
<mrutland>
Yeah, I suspect my board is different to yours in terms of boot configuration
<mmind00>
mrutland: probably not ... I probably just scrapped the other boot method on my board
<faddat>
mrutland / mmind: What is the sequence of commands you use to build a kernel? My friend and I are doing:
<mrutland>
faddat: I've extraced the original kernel. I'm first trying to verify that the whole flashing routine works, then I'll try to build a kernel.
<mrutland>
faddat: It's just a plain defconfig kernel build if you're using the right tree and branch
<mmind00>
mrutland: I think the order is try "boot" partition with an android boot image (identified by rockchip-checksum) and if this fails try kernel+resource partitions
<faddat>
(checked out the .dts and .dtsi files from for-next) make ARCH=arm64 rk3368-r88.img
<mmind00>
mrutland: in your kernel commandline you should see the mtdparts defs, can you post them
<mrutland>
faddat: As I said earlier, build an Image, not "rk3368-r88.img". Just drop "rk3368-r88.img" from your command line
<faddat>
no kiddin!
<faddat>
we're kinda in shock here ;), but my buddy, who made the boad just shouted "oh! I see now, I see now, I see now--" :)
<mrutland>
mmind00: that includes the CMDLINE and so on
<mmind00>
mrutland: yeah that works too ... as can be expected you can see resource+kernel, as well as boot partitions
<mmind00>
mrutland: I'm just always using the kernel+resource ones, as I somehow dislike the android boot.im stuff :-)
rubensm has joined #linux-rockchip
<mmind00>
mrutland: so one solution is (after saving its content) to write random garbage _without_ a rkcrc checksum to the boot partition
<mmind00>
mrutland: which then makes uboot fall-through to the other method ;-)
<mmind00>
mrutland: or try stuffing your kernel into an android boot.img ... depending on personal preference
faddat has quit [Remote host closed the connection]
faddat has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
<mrutland>
I see
<mrutland>
mmind00: I was under the (hopefully mistaken) impression that if I were to do that I wouldn't be able to flash the thing again. when I boot the board in flashing mode it still goes through U-Boot then stops in "#Boot ver: 2015-07-15#2.30", which I assumed lives in the boot partition.
<mrutland>
mmind00: I take it that you've nuked the boot prtition and can still flash your board
<mmind00>
mrutland: yep ... especially as the flash-code sits historically in the bootloader anyway :-)
<mmind00>
mrutland: but to ease your mind, let me hook up my board and check
<mrutland>
mmind00: Cheers. I'll just make a backup of my partitions in the mean time
<mmind00>
mrutland: if your seeing the following, you're just fine:
<mmind00>
#Boot ver: 2015-04-14#2.26
<mmind00>
empty serial no.
<mmind00>
checkKey
<mmind00>
vbus = 1
<mmind00>
rockusb key pressed.
<mmind00>
and still well within uboot (which is setting somewhere else altogether)
<mrutland>
Ok, I had assumed that lived in the boot partition, but evidently not
gouwa has joined #linux-rockchip
<mrutland>
I'm just waiting for backups to complete, then I'll nuke boot and corss my fingers :)
<mmind00>
mrutland: even with emmc devices they span their own abstraction layer on top ... which does not include the bootloader-area at all
<mrutland>
mmind00: Great. Major confusion for me here is simply the number of bootloaders and lack of documentation avaialble
<mmind00>
mrutland: you're not the only one :-)
<mrutland>
Nuked, now here comes the scary bit
<mrutland>
So after a power cycle I get no serial output whatsoever when truning the thing on, but rkflashtool can still talk to the board if booted into flashing mode
<faddat>
Hey, I'm in Shenzhen with my buddy Gouwa burning the midnight oil, and he and I just had a brain explosion, so we need to ask everyone here-- what is the form of the perfect 3368 or other Rockchip board? Board porn coming shortly....
<mmind00>
mrutland: try unplugging the serial? ... I remember the serial going abroad here sometimes too after power-cycles
<mmind00>
with most boards :-)
<mrutland>
Indeed!
<mrutland>
mmind00: I have a dmesg after power-cycling my FT2232H chip :)
<mmind00>
mrutland: oh great :-)
<mrutland>
mmind00: Just not the DTB I'd flashed on, Though I can't tell with the kernel either way
<mrutland>
mmind00: It seems to go straight to recovery if either boot or kernel are bad.
<mrutland>
bad image magic.
<mrutland>
load boot image failed
<mrutland>
ERROR: [rk_load_image_from_storage]: bootrk: bad boot or kernel image
<mrutland>
Unable to boot:boot
<mrutland>
try to start recovery
<mrutland>
So it looks like the nuke boot trick isn't sufficient
<mmind00>
mrutland: damn ... I'll dump what I have on those partitions here, maybe the sheds some light :-)
<mmind00>
mrutland: it looks like it checks for something before generating the "bad image magic" error ... so loading works and only later it encounters the non-working kernel it loaded ... but that is all voodoo there
<mrutland>
haha
<mrutland>
mmind00: Now I see "load fdt from resouce.", most of a kernel boot, then a panic
<mrutland>
Oh, sorry, not a panic. A lockup warning, then a hang
<mrutland>
Which I assume means it's now using my DTB, but failing to patch in stuff that it was trying to
<mmind00>
mrutland: likely ... now you just need to switch to mainline kernel :-)
<mrutland>
mmind00: yup. Happier doing that now I know I can still flash the thing regardless :)
faddat has quit [Ping timeout: 244 seconds]
faddat has joined #linux-rockchip
<mmind00>
mrutland: haha ... even if you destroy the bootloader people normally just short pins of the emmc/nand to make the rockchip socs drop to the maskrom (which also talks to rkflashtool from within the chip)
<mrutland>
mmind00: I guess i'm _far_ too cautious then! :D
<mmind00>
mrutland: nah ... I've also never tried this ... but knowing its there is reassuring nevertheless
faddat has quit [Ping timeout: 244 seconds]
gouwa has quit [Ping timeout: 246 seconds]
faddat has joined #linux-rockchip
gouwa has joined #linux-rockchip
faddat has quit [Ping timeout: 256 seconds]
faddat has joined #linux-rockchip
faddat has quit [Remote host closed the connection]
faddat has joined #linux-rockchip
markm has joined #linux-rockchip
gouwa has quit [Quit: Leaving]
gb_master has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
JohnDoe9 has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 244 seconds]
faddat has quit [Remote host closed the connection]
faddat has joined #linux-rockchip
JohnDoe9 has quit [Ping timeout: 264 seconds]
JohnDoe_71Rus has joined #linux-rockchip
faddat has quit [Remote host closed the connection]
faddat has joined #linux-rockchip
neyder_ has joined #linux-rockchip
neyder__ has joined #linux-rockchip
neyder__ has quit [Client Quit]
pizthewiz has joined #linux-rockchip
apritzel has quit [Ping timeout: 264 seconds]
gb_master has quit [Quit: Leaving]
faddat has quit [Remote host closed the connection]
faddat has joined #linux-rockchip
faddat has quit [Read error: Connection reset by peer]
GriefNorth has joined #linux-rockchip
RayFlower has quit [Ping timeout: 246 seconds]
<amstan>
rperier: you worked on an embedded linux distro right?
<amstan>
rperier: i'm interested to know what you think of it
<mmind00>
amstan: while I can't judge its viability, I can at least supply it was and still is Yocto rperier is working on :-)