Building 'latest' radxa kernel for Rock 5B

#1

Hi, I’m trying to build a kernel using the instructions from the wiki, however the mk-kernel/pack-kernel scripts are expecting arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts to exist and be compiled to rk3588-rock-5b.dtb but this file doesn’t exist in the default branch ie linux-5.10-gen-rkr4.1 so the scripts fail.

If I use the older linux-5.10-gen-rkr3.4 branch then the ‘new’ pwn_fan module isn’t present, so this doesn’t result in a kernel matching the one distributed in the official radxa debian image.

How do I build the ‘current’ kernel, from linux-5.10-gen-rkr4.1 branch? Are there newer versions of the build scripts floating around somewhere?

Thanks

#2

You can try alternative approach that has bigger certainty of success https://github.com/armbian/build

1 Like
#3

Thanks I’ll give that a try

#4

Armbian is proving to be unusable actually . It seems the Armbian kernel is incapable of read/write to the EMMC properly. Even just dd to/from it throws errors:

[   10.947385] blk_update_request: I/O error, dev mmcblk0, sector 60620675 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   10.949249] blk_update_request: I/O error, dev mmcblk0, sector 60620679 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   10.953967] blk_update_request: I/O error, dev mmcblk0, sector 60620675 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[   10.956079] blk_update_request: I/O error, dev mmcblk0, sector 60620679 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

This is causing armbian-install to fail, and results in an unbootable system. I’ve tried building the kernel myself as well as just flashing using the premade Armbian_23.5.1_Rock-5b_bookworm_legacy_5.10.160_minimal.img and Armbian_23.5.1_Rock-5b_jammy_legacy_5.10.160_minimal.img images from the Armbian website.

The Radxa Debian image does not have this problem. So I guess I’m back to my original question: How do I actually build the version of the kernel supplied in that official debian image? I’m guessing manually and not using the build scripts provided by Radxa.

Edit: I have a second eMMC. When I have a minute I’ll try one of the earlier Armbian images, that still use 5.10.110 instead of 5.10.160 to test

Edit 2: I might have found the answer to the original question: ignoring the outdated wiki and using https://github.com/radxa-repo/bsp &/or https://github.com/radxa-repo/rbuild possibly… maybe?

#5

Armbian is primarily a build framework, which obviously did the job perfectly. It also does it for hundreds of other boards. Perhaps make a donation to support people that are taking care of this system that removes many problems you might bump into?

If hardware of your interest doesn’t function well, talk to vendor (which you do via this forum. I am not associated, so I can’t answer). They are responsible to some degree. If they have changed hardware component, which is nothing unusual in this world, and they didn’t notify (and cover costs associated with the change) Armbian (or upstream in general), than this is their fault. Perhaps its something else? In any case, it needs investigation, before blaming. Especially you can’t blame gifted software support :wink:

Armbian is using its own Rockchip kernel fork https://github.com/armbian/linux-rockchip where things were ported from Radxa kernel.

I just tried to help with hints, for investigation I don’t have time.

#6

I’ve used these with success for rock pi 4, radxa zero and e25 builds. The bsp repo can build u-boot and the kernel. You can then use those packages with rbuild.

1 Like
#7

FYI radxa-repo/bsp is currently targeting rkr3.4 for the Rock 5B. I think official support from Radxa for rkr4.1 isn’t available yet (but when it is, it should be via radxa-repo/bsp).

1 Like
#8

I’ve managed to reproduce the kernel, using linux-5.10-gen-rkr3.4 and copying the config from the distributed debian image’s kernel instead of starting from rockchip_linux_defconfig.

#9

You probably could have skipped the reply to this posting.

1 Like
#10

It also provides prebuilt images including a kernel, which IMO makes it a distribution as well. I was just noting the experience I had with these - in case someone could point out something I had done wrong, or a known-working previous version I could try.

You allege it will remove those problems, I haven’t witnessed that yet. But I don’t doubt it… Still, this plug from you seems a bit self-serving, please stop. If I end up using Armbian and deriving value from it I would gladly donate but I don’t appreciate this spruiking

Which is why I posted my original question here, and not on the Armbian forums.

Which is why I said I would try, when I have time, one of the earlier Armbian images that uses 5.10.110 instead of 5.10.160 - because as we both know it’s far more likely there’s a regression in .160 than hardware being changed en masse but Radxa’s older kernels still working with it without modification.

I get it, you’re proud of your work, and so you should be - but please stop. The tone of your reply is bordering on arrogant now

I wasn’t asking for you to investigate, just sharing the experience and hoping someone else who’d been through it could direct me towards a solution - ideally one not soliciting donations in the process.

4 Likes
#11

Doesn’t change anything. tl;dr; Support is still only best effort.

That would be extremely helpful, but providing such service is also very expensive - for all boards and their revisions there are. Sure. How to cover? Or how to make this without finances? Both answers works for me. This is open source and perhaps you can start working on a project to provide that information? Everyone will gladly take results of your hard work and provide that added value to users for free.

Armbian is just one small project that is contributing to open source in general. Most of users / projects are just taking and most users just complaining. We won’t change that.

What about all those features that works well and were fixed by Armbian team? You ran just into one problem and all others have to be covered by “lazy” developers? I don’t have info for other similar projects, but here donations of end users never covered more then 0.5% of fixed costs. And you will only donate if solution for the problem you have is found.

Didn’t you notice “:slight_smile:” in my reply? That should disarm the tone. Not sure which part might sounded arrogant, but this forum is gifted software support too.

Yes, you did it right. Shared observation of the problem. And I gave you one hint, which proves to be “not good enough” … Without investment into your problem, which I have to skip, I can only help with general hints. If you know all this, perhaps to others that will read this.

Good luck.

#12

Try this 5A corrupts eMMC (was 5A does not boot)

#13

I didn’t ask you for support and I’m really unsure why you think I did. You were quick to point out that Armbian is a build framework and therefore absolved of any blame, which I agree with, but how can I refer to the kernel I tested as being the one with the problem without mentioning where I sourced it? this isn’t asking you or Armbian for support either, it is, again, just posting my experience in the hope that other users have been down this path and might know of a working version or at least verify the issue so I know it’s not just my hardware. This isn’t requesting or expecting any effort from you at all.

See above, again, I’m not requesting any of this from you and certainly don’t expect you to spend any time or money to resolve this issue with the kernel I tested. I’m sorry if anything I’ve said or done makes you think I expect free support from you - I do not. But I would like to be able to discuss experiences here without people becoming defensive of their very impressive pet projects :wink:

Thanks. And I will gladly report back any findings regarding kernel regressions once I can test - without any burden on you or the rest of the Armbian project

2 Likes
#14

This does sound similar, except I’m not seeing it on anything except 5.110.160 yet. I’ll read through the thread for any clues. Thanks

#15

Focus here:

Too optimistic settings for eMMC speed looks like a very possible problem. Fix is disabling HS400 as suggested in that post. I would try this first.

1 Like
#16 
[Sun Jul  2 21:38:08 2023] mmc0: new HS200 MMC card at address 0001

Yep, that is a very likely candidate for the issue. The ‘working’ kernel is using HS200