Jump to content

Mainline u-boot meson64

TonyMac32

By TonyMac32
in Amlogic meson

 Share

Recommended Posts

TonyMac32

TonyMac32

Posted
Posted

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
Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
  • Author
Posted

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...  :P

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
  • Author
Posted

Alright, highlighters and :beer: 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...  :ph34r:    :P

 

[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.  :lol:

 

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

 

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
  • Author
Posted
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.  :P And yes, that caused me some frustration.  :lol:

 

 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. 

 

 

 

 

 

 

 

Link to comment
Share on other sites
Neil Armstrong

Neil Armstrong

Posted
Posted

@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.

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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. 

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
  • Author
Posted

@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.

Link to comment
Share on other sites
Neil Armstrong

Neil Armstrong

Posted
Posted
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

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
  • Author
Posted

@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

Link to comment
Share on other sites
Neil Armstrong

Neil Armstrong

Posted
Posted
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
Link to comment
Share on other sites
Igor

Igor

Posted
Posted

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? 
 

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept