Jump to content

U-Boot and Linux 5.8+


Recommended Posts

It seems the Linux kernel 5.8+ on aarch64 is incompatible with the U-Boot from 2017, at least on the RK3328 boards. This apparently affects the Rock64 as well as my own Renegade.
Essentially U-Boot gets stuck on "Starting kernel..."


In this post https://archlinuxarm.org/forum/viewtopic.php?f=23&t=14657&start=10 they fix it by recompiling u-boot, newer version from upstream

In addition to the existing rock64 defconfig, it seems that the defconfig for the Renegade was finally upstreamed on May!
https://github.com/u-boot/u-boot/commit/bab972948e152e468fa5ab34764769fc4cddcaab

No more 2017 U-Boot from rockchip for me, perharps...
I modified https://archlinuxarm.org/packages/aarch64/uboot-rock64/files/PKGBUILD for the renegade and actually got a system that can boot Linux 5.8. (flashed the loader1 and an .itb file)

I have 2 (possibly 1) issue:
1) Like the current branch in the armbian build, uboot is missing the ums (USB mass storage) command which is really useful to modify the emmc from a pc.
2) The 2020 uboot i compiled shows DDR4 333 in the first stage, instead of the older DDR4 786Mhz. Does that mean the RAM gets initialized at a lower speed? Maybe, but at least I can boot newer kernels now.

Also Maybe the Rock64 and Renegade armbian packages should actually use the upsteam uboot instead of rockchip's 2017 version. I don't know if you already do this in the build tools, but it would be cool!

Link to comment
Share on other sites

The current plan regarding legacy u-boot for rockchip64 is to get rid of it for v20.11:

https://armbian.atlassian.net/browse/AR-350

https://armbian.atlassian.net/browse/AR-351

 

I will add a separate issue for Renegade to not forget it in the process ;p

 

3 hours ago, jpegxguy said:

missing the ums (USB mass storage) command which is really useful to modify the emmc from a pc

I believe we could try to enable it.

 

3 hours ago, jpegxguy said:

shows DDR4 333 in the first stage, instead of the older DDR4 786Mhz

Current Rockchip's DDR loaders are also limited to 333MHz but we have DMC enabled in mainline kernels for rk3328 and higher frequencies should be used.

What do you see when you run the following command?

cat /sys/class/devfreq/dmc/trans_stat

 

EDIT: Rock64 boots fine with 5.8.x and u-boot v2017.09: http://ix.io/2uyG so the issue might be isolated to Renegade...

Link to comment
Share on other sites

Thanks for the answer!

 

Yes it would be awesome if UMS was enabled!

 

cat: /sys/class/devfreq/dmc/trans_stat: No such file or directory

Specifically, there is nothing under the devfreq directory.

 

I'm running Linux 5.8 on ArchLinuxARM. The guys on the archlinuxARM forum are having (at least one of them) the same issue of getting stuck in "Starting kernel..." when using Rock64 and Linux 5.8, so it's not isolated to Renegade
Maybe it has something to do with that distro's specific Linux 5.8 version?

Link to comment
Share on other sites

2 hours ago, jpegxguy said:

I'm running Linux 5.8 on ArchLinuxARM

This was really missing in your opening message... I thought you were simply referring to what you found in Arch ;-)

 

2 hours ago, jpegxguy said:

Specifically, there is nothing under the devfreq directory.

Yes. When I wrote "we have DMC enabled" I meant "in Armbian". It's not available in mainline.

This most probably means your memory is staying at 333MHz all the time.

One more way to verify this would be to use:

grep ddr /sys/kernel/debug/clk/clk_summary

 

Did you try to build yourself a "dev" image for Renegade from Armbian master and see if the boot problem exists here too?

Link to comment
Share on other sites

5 hours ago, jpegxguy said:

Yes it would be awesome if UMS was enabled!


Indeed. If code was not mainlined ... there is a huge wish list (Armbian only) -> https://forum.armbian.com/forum/38-feature-requests/ and zero budget for realisation.
 

We only cover UMS with a bunch of patches on Tinkerboard. Even there it become troublesome to move along which is why u-boot is kept back.

 

5 hours ago, jpegxguy said:

Maybe it has something to do with that distro's specific Linux 5.8 version?

 

Since Armbian does not provide 5.8.y yet, and its away from reckless "bleeding edge" Arch/Manjaro this is in fact not a problem we would need to solve (for Arch/Manjaro). Moving to development forums. We will deal with this once we start moving our development builds to 5.8.y

Link to comment
Share on other sites

I definitely agree that it's not your concern if it's an Arch issue. I wanted to post because the whole mainline experiment with U-Boot. I really appreciate this project and its efforts with these funky Rockchip boards!

 

So UMS is not an upstream thing? Is it that it needs a lot of board-specific patches?

 

EDIT:

# grep ddr /sys/kernel/debug/clk/clk_summary
    clk_ddrmon                        0        0        0    24000000          0     0  50000
                   pclk_ddrphy        1        1        0    75000000          0     0  50000
          pclk_ddr                    3        3        0   150000000          0     0  50000
             pclk_ddr_grf             1        1        0   150000000          0     0  50000
             pclk_ddrstdby            0        0        0   150000000          0     0  50000
             pclk_ddr_mon             1        1        0   150000000          0     0  50000
             pclk_ddr_msch            1        1        0   150000000          0     0  50000
             pclk_ddrupctl            0        0        0   150000000          0     0  50000
          clk_ddr                     2        2        0   664000000          0     0  50000
             aclk_ddrupctl            0        0        0   664000000          0     0  50000
             clk_ddrupctl             1        1        0   664000000          0     0  50000
             clk_ddrmsch              1        1        0   664000000          0     0  50000

Which clock do i care about?

Link to comment
Share on other sites

13 hours ago, jpegxguy said:

So UMS is not an upstream thing? Is it that it needs a lot of board-specific patches?


At the time it wasn't. Now - I don't know. Is it possible to just enable it on all hardware? I don't know. To know, a research has to be done. Many nice features also never reaches mainline or they reaches and somebody has to deal with integration and keep it operational at version change. Plug and play things are rare at this level.

Link to comment
Share on other sites

36 minutes ago, jpegxguy said:

to boot Linux 5.8


This is what I don't understand. Arch "mainline" 5.8.y kernel is behind our "mainline" 5.7.y and recent u-boot has many disadvantages. In term of user land, ok, its your choice.

Link to comment
Share on other sites

5 hours ago, Igor said:


This is what I don't understand. Arch "mainline" 5.8.y kernel is behind our "mainline" 5.7.y and recent u-boot has many disadvantages. In term of user land, ok, its your choice.

Thinking longterm, I don't want to be stuck to legacy kernels. Of course I like the ums in the legacy uboot, it's just my solution for now

Link to comment
Share on other sites

37 minutes ago, jpegxguy said:

I don't want to be stuck to legacy kernels


Where on earth did you find legacy kernels???? Armbian provides highly improved mainline kernels everywhere this is possible. Arch builds raw Linux kernel which can be a year behind ours. On some platforms we still do provide legacy kernels because this is good and because we can. 

Link to comment
Share on other sites

6 hours ago, Igor said:


This is what I don't understand. Arch "mainline" 5.8.y kernel is behind our "mainline" 5.7.y and recent u-boot has many disadvantages. In term of user land, ok, its your choice.

Armbian's kernels are fine! What I mean is that with the rockchip U-Boot I had before, I would not be able to run kernels past 5.8, at least on the distro I run on that card (Arch), which would be a problem for security in the future.
I'd be stuck on 5.7 for example, with 5.10 being out... (e.t.c)

Link to comment
Share on other sites

1 minute ago, jpegxguy said:

which would be a problem for security in the future.


Problem of security is lack of maintenance. 

 

2 minutes ago, jpegxguy said:

I'd be stuck on 5.7


Perhaps for two weeks. That's really awful.

Link to comment
Share on other sites

42 minutes ago, Igor said:


Problem of security is lack of maintenance. 

 


Perhaps for two weeks. That's really awful.

There would be a lack of maintenance because 5.7 is not an lts version. 5.4 does exist though which is nice.

Wait, why for 2 weeks? I was thinking I wouldn't be able to boot anything past 5.8.0.

Link to comment
Share on other sites

4 minutes ago, jpegxguy said:

There would be a lack of maintenance because 5.7 is not an lts version. 5.4 does exist though which is nice.


Latest stable kernel is yet to be stabilised in next weeks / months. And this is not Intel, but ARM Rockchip, which adds complexity. I can assure you that staying on a bleeding edge is asking for troubles - you found one, but there are more, which autotesting can't find - and taking raw kernel from kernel.org is something anyone can do. We add weeks, sometimes months of work on top of that raw material, a lot of fixes yet to come to the mainline are already a part of our kernel. That's what I am trying to point out. Either goes for fixes or for adding features. Mainly we are focused to hardware specifics - exactly what you will miss on a generic kernel. Yes, we can't solve everything, but the end result is usually better, much better. BTW.

 

10 minutes ago, jpegxguy said:

Wait, why for 2 weeks? I was thinking I wouldn't be able to boot anything past 5.8.0.


Well, for you this is probably not relevant, since you are using distribution that provides generic Linux kernel.

 

We will probably move to 5.8.y soon, but there is no urgency - we already support more important hw specific features/fixes that are in 5.8.y. while general improvements from 5.7 -> 5.8 are too small to bother.

 

Also we can decide upgrade per hardware family. For one this is good, for another this is bad, one will not boot at all, one have to stay behind ... not all hardware is getting good mainline support.

Link to comment
Share on other sites

On 8/18/2020 at 12:31 PM, jpegxguy said:

Essentially U-Boot gets stuck on "Starting kernel..."

Maybe change "verbosity=1" to "verbosity=7" ...

 

Because I've currently my Rock64 working since a week with a build done with 5.8.1 kernel, and of course still using U-Boot 2017.09.

Link to comment
Share on other sites

11 hours ago, Igor said:


Latest stable kernel is yet to be stabilised in next weeks / months. And this is not Intel, but ARM Rockchip, which adds complexity. I can assure you that staying on a bleeding edge is asking for troubles - you found one, but there are more, which autotesting can't find - and taking raw kernel from kernel.org is something anyone can do. We add weeks, sometimes months of work on top of that raw material, a lot of fixes yet to come to the mainline are already a part of our kernel. That's what I am trying to point out. Either goes for fixes or for adding features. Mainly we are focused to hardware specifics - exactly what you will miss on a generic kernel. Yes, we can't solve everything, but the end result is usually better, much better. BTW.

 


Well, for you this is probably not relevant, since you are using distribution that provides generic Linux kernel.

 

We will probably move to 5.8.y soon, but there is no urgency - we already support more important hw specific features/fixes that are in 5.8.y. while general improvements from 5.7 -> 5.8 are too small to bother.

 

Also we can decide upgrade per hardware family. For one this is good, for another this is bad, one will not boot at all, one have to stay behind ... not all hardware is getting good mainline support.

That's true, and I think Armbian is essentially the only way if you plan on using these boards' hardware, like hardware acceleration e.t.c. I do look around in the armbian build repo and there are always nice patches and fixes in the patch/ directory. I have SD cards with Armbian, Arch and other distros, and I only stick to Arch on headless because I'm less familiar with debian packaging. If I wanted to run anything more damanding than SMB or a torrent client I'm pretty sure Armbian is the only distro with support for these ARM boards' quirks. Generic distros like Debian, or Ubuntu or Arch are better suited for hardware with good upstream (Rockchip in this case) support

Link to comment
Share on other sites

10 minutes ago, jpegxguy said:

because I'm less familiar with debian packaging.


That I can understand.

 

10 minutes ago, jpegxguy said:

Generic distros like Debian, or Ubuntu or Arch are better for hardware with better upstream (Rockchip in this case) support


They are better, yes, but still not close to our level. And also remember why and where you brought up this topic. If that is not a huge difference, then what is?

Link to comment
Share on other sites

Yeah, I just like the Arch way of things. I started with Ubuntu like most people, and I do run Debian on one of the machines, but on my laptop I use Arch™

As for Debian being "better" I mean in the sense of "even being doable",. I brought the U-Boot upstreaming topic here because this distro does care to bring U-Boot and the like to more boards than other distros, especially ones that are not ARM-specific.

As I mentioned, I didn't even know some defconfig for Renegade had been upstreamed! It was only Rock64 before, haha

Link to comment
Share on other sites

In light of a recent change of role for this Renegade board (It'll be a small headless server on a different location from me), I've switched it to Armbian!

The changes I've made besides the usual config are: GPT  (Not necessary: I just like the checksumming + backup partition table) and U-Boot switch to legacy channel because that channel has the ums U-Boot command.

I figured Armbian would be less risky for stability, especially for kernel upgrades on a device I don't have physical access to. The armbian-config and relevant utilities are nice too.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines