TonyMac32 Posted May 30, 2018 Posted May 30, 2018 I have created a branch for amlogic device mainline u-boot, I have successfully booted le potato now, it took some small adjustments to support the 2015 boot script. Anyone wishing to try this use LIB_TAG="meson64-uboot" Next steps: use a proper boot script to take advantage of armbianEnv.txt and bring Le Potato to modernity. using C2 as pattern bring up mainline support for K2 1
TonyMac32 Posted May 31, 2018 Author Posted May 31, 2018 I don't prefer to "call in the artillery", but I've run into a wall on making the "u-boot.bin.sd.bin" for the NanoPi K2. The U-boot part of it is honestly done with the gxb work, just making it it's own entries and such with minor tweaks where necessary, but the Amlogic FIP stuff is just... ugh. The C2 has a special "bl1" as they call it, so that method isn't correct, and reading through the make file in the amlogic u-boot is making me wish for sharp objects to poke out my eyes. If @balbes150 or @Neil Armstrong know the steps to meld the blobs and the u-boot.bin right off the top of their heads, that would be amazing and I can wrap this up. If not, I'm printing a Makefile and getting at least 4 different colored highlighters...
TonyMac32 Posted June 4, 2018 Author Posted June 4, 2018 Alright, highlighters and it is. There looks like about 3 pages of code linked to this, and it's only 75% variable names, so it shouldn't be that bad. ...or I could just add V=1 to the mk script... [update] Image is successfully made, it freezes on loading bl33, so I have some board init work to do, I took a gamble that it was nearly identical to the Odroid-C2 and lost. The u-boot.bin.sd.bin appears to be the proper format, data where it goes (hex editor and comparison with the actual Amlogic build environment results) If something I'm not smart enough to see is in the text below, let me know. no sdio debug board detected TE: 286127 BL2 Built : 11:58:33, May 27 2017. gxb gc3c9a84 - xiaobo.gu@droid05 set vcck to 1100 mv set vddee to 1000 mv Board ID = 8 CPU clk: 1536MHz DDR chl: Rank0+1 same @ 912MHz DDR0: 2048MB-2T-13 DataBus test pass! AddrBus test pass! Load fip header from SD, src: 0x0000c200, des: 0x01400000, size: 0x00004000 Load bl30 from SD, src: 0x00010200, des: 0x01000000, size: 0x0000d460 Sending bl30......................................................OK. Run bl30... Load bl31 from SD, src: 0x00020200, des: 0x051000[00, size: 0x00016380 Image: gxb_v1.1.3221-2cfba69 2017-05-27 16:04:23 qiufang.dai@droid07] OPS=0x13 efuse_setup() 573: HDCP=0x0c REG32(SEC_AO_SEC_SD_CFG9)=0x00000007 f8 a2 41 21 93 17 68 97 41 23 b a7 [0.385967 Inits done] secure task start! high task start! low task start! Load bl33 from SD, src: 0x00038200, des: 0x01000000, size: 0x0006ace0
balbes150 Posted June 4, 2018 Posted June 4, 2018 I'm sorry, but I don't understand what the problem is ?
TonyMac32 Posted June 4, 2018 Author Posted June 4, 2018 On 6/4/2018 at 3:02 AM, balbes150 said: I'm sorry, but I don't understand what the problem is ? Using u-boot 2018.03. ;-) . The problem was how to get the binary blobs into the right order, I hadn't looked closely enough. Now that I have that, I need to properly power-up the K2. This is to move forward from the 2015.01 blob we use right now. [edit] The issue was the odd-ball fip_create in the repo we keep the blobs. The hardkernel fip_create tool is not compatible with any newer blobs. Used the proper tool and booted it right up with u-boot 2018.03. @Igor I will push these final adjustments and merge the code if no one has any objections. There has been a PR open if others wanted to test with Le Potato, so far I've had no concerns with it.
Igor Posted June 5, 2018 Posted June 5, 2018 Good job! So we can rebuild images for K2 and Le Potato ASAP or just nightly?
TonyMac32 Posted June 5, 2018 Author Posted June 5, 2018 I would wait on images until we get the bootscripts "up to code" with what is expected. I'll need some help there. Then we'll have armbianEnv.txt and such. I made sure the existing boot scripts worked before putting in the PR, so nightly will be ok.
Neil Armstrong Posted June 6, 2018 Posted June 6, 2018 @TonyMac32 Hi, I just realized you were making a K2 port of U-boot. First, avoid 2018.03 since the MMC driver is buggy and crashes at boot, switch to 2018.05 or 2018.01. Did you push your code somewhere ? I'll be interested to have it pushed on U-boot mainline !
TonyMac32 Posted June 6, 2018 Author Posted June 6, 2018 4 hours ago, Neil Armstrong said: First, avoid 2018.03 since the MMC driver is buggy and crashes at boot, switch to 2018.05 or 2018.01 We have a patch for that. And yes, that caused me some frustration. I've been tracking the progress upstream, I just wanted to see if I could do it, especially the fip magick. It is so far just a clone of the C2 code using the generic gxb blobs and a K2 dts, I'm planning on moving to the newer u-boot soon, my first experiments were before it was final so I stuck with .03 It's in patch form in the build system: https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-meson64 And blobbing it all into u-boot.bin: https://github.com/armbian/build/blob/master/config/sources/meson64.conf You'll see the subsection, it's huge. The "odroidc2-blobs" directory is so named because it was the first board, each board has a folder inside there with appropriate blobs.
Neil Armstrong Posted June 8, 2018 Posted June 8, 2018 @TonyMac32 Ok i didn't find the patch myself... There is no real magic in FIP. The problem is that HardKernel make some changes to the u-boot build system for the FIP stuff, but the K2 follows the "standard" AMlogic way to build it. So it should be more like the GXL based uboot, but for GXBB. Do you want to push the patch to u-boot upstream ? I can push it and retain your authorship if you want.
Igor Posted June 8, 2018 Posted June 8, 2018 On 6/6/2018 at 9:39 AM, Neil Armstrong said: driver is buggy and crashes at boot, I was testing 2018.05 with our latest kernels yesterday and noticed another odd thing. Reported K2 SoC temperature is 15-20 higher compared to measurements.
TonyMac32 Posted June 10, 2018 Author Posted June 10, 2018 @Neil Armstrong I forked the current github u-boot and adjusted for the renaming of gxbb to gx, I've been focusing on Rockchip for testing last several days so I won't gauruntee no typos, and the readme is incomplete, needs the details about where to get blobs and the fip script. Https://GitHub.com/tonymac32/u-boot I just used the generic gxbaby blobs here so far, that shouldn't have anything to do with the temperature readout should it? I haven't spent a ton of time debugging, the memory allocation patch I'd applied to the kernel a while back unfixed itself as adjustments were made upstream and I abandoned the old bootloader. I see some patches in there now to address it, but I figured mainline was a better solution for my sanity and our uses here.
Neil Armstrong Posted June 12, 2018 Posted June 12, 2018 On 6/10/2018 at 3:52 PM, TonyMac32 said: @Neil Armstrong I forked the current github u-boot and adjusted for the renaming of gxbb to gx, I've been focusing on Rockchip for testing last several days so I won't gauruntee no typos, and the readme is incomplete, needs the details about where to get blobs and the fip script. Https://GitHub.com/tonymac32/u-boot I just used the generic gxbaby blobs here so far, that shouldn't have anything to do with the temperature readout should it? I haven't spent a ton of time debugging, the memory allocation patch I'd applied to the kernel a while back unfixed itself as adjustments were made upstream and I abandoned the old bootloader. I see some patches in there now to address it, but I figured mainline was a better solution for my sanity and our uses here. @TonyMac32I took your changes and wrote the README to generate the binary and tested it, it worked like a charm ! https://github.com/superna9999/u-boot/commits/u-boot/topic/nanopi-k2 I can push them to uboot uptream if you can validate it also works on your side
TonyMac32 Posted June 13, 2018 Author Posted June 13, 2018 @Neil Armstrong I did a quick test, with my very primitive boot script I had a problem booting, uncovered: U-Boot 2018.07-rc1-armbian (Jun 12 2018 - 22:07:39 -0400) nanopi-k2 DRAM: 2 GiB MMC: mmc@70000: 0, mmc@72000: 1 In: serial@4c0 Out: serial@4c0 Err: serial@4c0 [BL31]: tee size: 0 [BL31]: tee size: 0 Net: Warning: ethernet@c9410000 (eth0) using random MAC address - 46:75:fe:24:98:2d eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 => mmc list mmc@70000: 0 mmc@72000: 1 It's trying to use the WiFi as mmc 0. I only avoided this because I didn't have the wifi in my device tree (had errors). I don't know if defining the boot targets per board would help since mmc 0 will always be the WiFi, unless the numbers are unrelated between that #define and the resulting environment assignments... Otherwise good to go, and I would guess this shouldn't be a problem for properly written scripts
Neil Armstrong Posted June 13, 2018 Posted June 13, 2018 5 hours ago, TonyMac32 said: @Neil Armstrong I did a quick test, with my very primitive boot script I had a problem booting, uncovered: U-Boot 2018.07-rc1-armbian (Jun 12 2018 - 22:07:39 -0400) nanopi-k2 DRAM: 2 GiB MMC: mmc@70000: 0, mmc@72000: 1 In: serial@4c0 Out: serial@4c0 Err: serial@4c0 [BL31]: tee size: 0 [BL31]: tee size: 0 Net: Warning: ethernet@c9410000 (eth0) using random MAC address - 46:75:fe:24:98:2d eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 => mmc list mmc@70000: 0 mmc@72000: 1 It's trying to use the WiFi as mmc 0. I only avoided this because I didn't have the wifi in my device tree (had errors). I don't know if defining the boot targets per board would help since mmc 0 will always be the WiFi, unless the numbers are unrelated between that #define and the resulting environment assignments... Otherwise good to go, and I would guess this shouldn't be a problem for properly written scripts @TonyMac32 It's not an issue, u-boot will cycle over all mmc interfaces, numbers are unrelated, mmc0 is the first mmc interfaces, on Potato it's the SDCard. 1
Igor Posted June 26, 2018 Posted June 26, 2018 I am doing some housecleaning on our meson64 family patches and configs, merging with C2 which is the primary goal and removing odroidc2 family at the end. Odroid C2 legacy kernel was also upgraded to 3.16.y, NEXT/DEV is 4.16.y, meson64 and odroidc2 (can) use the same config, (almost - packaging hacks) same kernel patch set. Boot commands: we have booti on C2 next, bootz on C2 default, booti on Meson64 old and bootm on Meson64 NEXT ... uImage, zImage, Image ... is there anything to have this under one simplified boot script? Any ideas in which direction to go would help! @Neil Armstrong You have any idea how to boot legacy 3.14/3.16 C2 kernel with a modern u-boot?
Recommended Posts