10:29 <Darkmatter66_> HI

10:29 <Darkmatter66_> I have two questions about u-boot

10:30 <Darkmatter66_> 1- is it possible to extract the config from u-boot binary ? something like ./scripts/extract-ikconfig in Linux ?

10:31 <Darkmatter66_> 2- can I flash mainline u-boot on my box and still be able to boot to vendor Android ? or do I need Vendor u-boot to boot vendor u-boot?

11:35 <chewitt> Darkmatter66_ most vendor u-boot configs allow you to disrupt boot via uart (hit space or enter at the right moment) and this drops you to the u-boot console where you can run "print env" and it will show you the mountain of crap bootscript being used. As long as you replicate the same (or similar) you should be able to continue booting Android.

11:38 <Darkmatter66_> chewitt, Yes I was going to do that but thought i ask first if anyone tried it to avoid the pain of trying, also what about the TEXT_OFFSET difference between mainline and vendor kernel?

11:40 <chewitt> the alternative is chain-loading u-boot with a more vanilla version

11:40 <chewitt> s/the/an

11:41 <chewitt> we've been experimenting with that to sidestep the RGB/YUV issue on newer boards, but since those are still derived from "2015" vendor u-boot, the same approach should work

11:41 <chewitt> which text offset are you talking about?

11:42 <chewitt> nb: not my area of expertise, but two guesses are better than one, right!?

11:43 <chewitt> btw, I picked your commits from Kevin's 5.6 branch for LE use :)

11:55 <Darkmatter66_> chewitt, nice, I also sent an rc keymap patch to the linux-media guys but no response so far !

11:55 <Darkmatter66_> chewitt, https://github.com/khadas/fenix/blob/master/packages/linux-mainline/patches/5.0.4/0087-GX-update-TEXT_OFFSET-for-Amlogic-MESON-SoC.patch

11:55 <Darkmatter66_> chewitt, ^ this is the TEXT_OFFSET patch I'm talking about

11:56 <ukleinek> in my experience chainloading in U-Boot is harder than should be necessary because you have to care for cache cleanup

11:57 <chewitt> I never had a response to any of the remotes that I submitted semi-recently .. until I got an "applied to branch" notification

11:57 <chewitt> remotes aren't particularly important so I guess they just trawl the list and merge them periodically

12:00 <Darkmatter66_> ukleinek, Cache cleanup ?

12:01 <Xogium> I tried to chainload vendor u-boot -> mainline u-boot once. I never made it work

12:01 <Darkmatter66_> chewitt, they are important for amlogic to use the power button to hibernate the device at least

12:02 <Xogium> I wanted to have a tiny u-boot in the spi flash, then chainload another u-boot that was on mmc

12:02 <Darkmatter66_> Xogium, I've sucessfully chainloaded vendor u-boot -> mainline u-boot before with the help of narmstrong, even got video output of u-boot

12:02 <Xogium> all I managed to do was to crash my board in a loop

12:03 <Xogium> I think it was because my chainloaded u-boot attempted to setup ram and all that

12:04 <Xogium> and the tiny u-boot had already done that

12:05 <narmstrong> Sees you chainloaded with the full binary packed with fip binaries, just use the result of make in uboot

12:05 <narmstrong> It works fine

12:05 <Darkmatter66_> Xogium, If I remember correctly you need to take the raw u-boot.bin

12:06 <Xogium> but I must not let it run the board_init or whatever

12:06 <Xogium> right ?

12:06 <Darkmatter66_> Xogium, as narmstrong said above, don't go through the fip packing steps, just take u-boot.bin from the main tree after running make

12:07 <Xogium> yeah but that u-boot.bin has a board_init function

12:07 <Xogium> I'll try to play with it some more

12:08 <Darkmatter66_> Xogium, just put u-boot.bin on an sd card, when the vendor u-boot starts interrupt it and chainload the mainline u-boot.bin

12:09 <Darkmatter66_> Xogium, These are the commands that worked for me https://termbin.com/wn5r

12:09 <Xogium> whoever ported this board to mainline did it wrong anyway… I'd switch to direct mainline, but its bugged, and I'm hoping to avoid these issues by chainloading from the vendor u-boot. The mainline version doesn't talk to ATF to determine available ram, the dts is done badly so that usb 3 is mixed up with pcie and crashes the board, and the env is saved to the wrong place

12:10 <Darkmatter66_> Xogium, be sure to change the partition number in the first command

12:11 <Xogium> fixing the dts and the place where the env is saved is easy, but fixing the code so that u-boot talks to ATF to check the ram amount… No bloody clue how

12:12 <chewitt> Xogium: which board?

12:12 <Xogium> a marvell one :p or should that be globalscale ? Espressobin

12:14 <Xogium> try to get a pcie port running at 6 gb/s, see if u-boot will agree :p

12:15 <Xogium> here it didn't, and got stuck in a boot loop :D no wonder, that pcie port is supposed to be 2.5 gbps afaik

12:17 <Xogium> also sata ain't working with mainline, but its not a big deal for me since I'm not using it

12:18 <Xogium> its just that the vendor fork will be a year old in a couple days, and I doubt it will evolve further, not even to backport bugfix

12:18 <Xogium> scratch that, the u-boot itself is nearly 2 years old

12:20 <Xogium> I'll try to mess around with chainloading, thanks narmstrong and Darkmatter66_

13:26 <ukleinek> Darkmatter66: yes, if you chainload another bootloader using "go" the first U-Boot doesn't do cache maintenance and the 2nd assumes a clean and disabled cache. Believe me, that is really bad to debug and can take much time to debug and understand

13:43 <narmstrong> haven't got any issue with chainloading for now...

13:44 <narmstrong> and the board_init() on amlogic u-boot doesn't initialize DDR or anything, so it's safe to chainload

13:46 <ukleinek> narmstrong: some U-Boot binaries don't enable Caching at all, in this case it's safe.

13:47 <ukleinek> narmstrong: alternatively you must wrap the image using mkimage and use bootm to start it. Then the caching is handled as expected.

17:18 <Darkmatter66> narmstrong, If I've burnt the u-boot to the sdcard how do i tell the device to load the u-boot on the sdcard ?

17:43 <Darkmatter66> narmstrong, at the time I added support to my board to u-boot i didn't use the fip package, i only chainloaded so I copy pasted the instructions from other READMEs but looking at them now they are incorrect

17:43 <Darkmatter66> https://github.com/u-boot/u-boot/blob/master/board/amlogic/p201/README.p201

17:43 <Darkmatter66> https://github.com/u-boot/u-boot/blob/master/board/amlogic/p200/README.p200

17:44 <Darkmatter66> narmstrong, these instructions use $FIPDIR/gxl blobs and tools while they should use $FIPDIR/gxbb

17:45 <Darkmatter66> narmstrong, I want to update these documents but I'm not able to execute the u-boot from sdcard

17:45 <Darkmatter66> narmstrong, also there are differences in instructions between gxb and gxl beyond the fip directory

17:47 <Darkmatter66> narmstrong, for example https://github.com/u-boot/u-boot/blob/master/board/amlogic/p200/README.odroid-c2 this uses fip_create while gxl boards don't use it

17:48 <Darkmatter66> narmstrong, this https://github.com/u-boot/u-boot/blob/master/board/amlogic/p212/README.p212 burn the u-boot.bin.sd.bin while other machines just burn the u-boot.bin

17:48 <Darkmatter66> narmstrong, so many steps and differences it's hard to know which step applies to my board

22:12 <narmstrong> Darkmatter66: look at the nanopi-k2 steps, it should be close