XPost: linux.debian.ports.arm

On Sunday, 30 April 2023 23:28:23 CEST Roger Shimizu wrote:

Currently, the dev-board is supported by Linaro [2][3], and most
kernel device-tree, patches and firmware are already upstreamed.
I confirmed that with simple snippet below, generated boot.img can be
used to boot the RB3 / DB845c dev-board with linaro's rootfs [3].
PS. mkbootimg [4] is a tool from android's package to generate
boot.img image to boot the dev-board.

My question is:
- Currently flash-kernel is mainly u-boot based, is it proper to add "mkbootimg" based devices?

In https://lists.debian.org/debian-arm/2023/02/msg00023.html I said: ===================================================
If you have a working bootloader which (successfully) starts 'some' kernel and combine that with a userland created by f.e. debootstrap and you have a
working Debian-like system.

The problem with most BSPs is this: The device/chipset vendor proved with it that the device/SBC works and can run Linux. And then they throw it over the wall and 'say' "have fun with it" (our job is done)." ===================================================

Sound to me like yet another BSP.
In that same post I also said: ===================================================
I'm going to assume that "supported *in* Debian" (emphasis mine) means whether it's supported by all-and-only Debian packages.

For that you need 2 things:
1) device/SBC is supported by *upstream* u-boot
2) device/SBC is supported by the *upstream* kernel ===================================================
(Vagrant Cascadian replied to that post and mentioned UEFI as another 'valid' boot loader)

Booting ARM based devices is already complicated enough, so *I* would be very much in favor of NOT adding support for yet another boot method, which would also disincentivize board makers (and/or their community) from properly and fully upstreaming things, including u-boot/UEFI.

Not sure if my opinion is relevant as I also don't know much about flash-kernel, but these are my 0.02
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZE7lOAAKCRDXblvOeH7b btCJAP9ZsoMEzOkgLxipFGsElK35A1vqQfrtj8qRf7+Z9BUvvgEApcHlE1GmCS1d Wi57TVEE4KP4xg8P07Up9PHRSAxXqAo=
=oOl6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.arm

Hi there,

I'm trying to support an ARM based RB3 / DB845c [1] dev-board with android-style boot image to flash-kernel.
(Surely it's targeting to post-bookworm)

Currently, the dev-board is supported by Linaro [2][3], and most
kernel device-tree, patches and firmware are already upstreamed.
I confirmed that with simple snippet below, generated boot.img can be
used to boot the RB3 / DB845c dev-board with linaro's rootfs [3].
PS. mkbootimg [4] is a tool from android's package to generate
boot.img image to boot the dev-board.

My question is:
- Currently flash-kernel is mainly u-boot based, is it proper to add "mkbootimg" based devices?
- Does mkbootimg need to support udeb in order to support D-I for this dev-board in the future?

If this dev-board is feasible, I'm planning to add a few similar
dev-boards from the series.
So your advice will be appreciated!

====
gzip -c9 /boot/vmlinuz-6.1.0-8-arm64 > vmlinuz.gz
cat vmlinuz.gz /usr/lib/linux-image-6.1.0-8-arm64/qcom/sdm845-db845c.dtb > Image
mkbootimg \
--kernel Image \
--ramdisk /boot/initrd.img-6.1.0-8-arm64 \
--output boot.img \
--pagesize "4096" \
--base "0x80000000" \
--kernel_offset "0x8000" \
--ramdisk_offset "0x1000000" \
--tags_offset "0x100" \
--cmdline "root=PARTLABEL=rootfs console=tty0
console=ttyMSM0,115200n8 clk_ignore_unused pd_ignore_unused"
====

[1] https://www.96boards.org/product/rb3-platform/
[2] https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/latest [3] https://releases.linaro.org/96boards/dragonboard845c/linaro/debian/latest [4] https://packages.debian.org/unstable/mkbootimg

Cheers,
Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.arm

On 2023-04-30, Roger Shimizu wrote:

I'm trying to support an ARM based RB3 / DB845c [1] dev-board with android-style boot image to flash-kernel.

...

My question is:
- Currently flash-kernel is mainly u-boot based, is it proper to add "mkbootimg" based devices?

My main worry here is investing too much in flash-kernel, rather than
replacing it... both require possibly significant effort, and I wonder
if that effort would not be better spent writing a more modular
replacement for flash-kernel? That said, I have not mustered the energy
to do this myself...

To some degree, I have been the de-facto maintainer for flash-kernel,
but I am hesitant to make significant changes to it... it is not easy
code to read...

- Does mkbootimg need to support udeb in order to support D-I for this dev-board in the future?

I *think* that the udeb (indirectly?) calls flash-kernel inside the
chroot... so I am not sure that would be necessary. There's no
"u-boot-tools" udeb, and many boards use mkimage from "u-boot-tools".

gzip -c9 /boot/vmlinuz-6.1.0-8-arm64 > vmlinuz.gz
cat vmlinuz.gz /usr/lib/linux-image-6.1.0-8-arm64/qcom/sdm845-db845c.dtb > Image
mkbootimg \
--kernel Image \
--ramdisk /boot/initrd.img-6.1.0-8-arm64 \
--output boot.img \
--pagesize "4096" \
--base "0x80000000" \
--kernel_offset "0x8000" \
--ramdisk_offset "0x1000000" \
--tags_offset "0x100" \
--cmdline "root=PARTLABEL=rootfs console=tty0
console=ttyMSM0,115200n8 clk_ignore_unused pd_ignore_unused"

That seems "simple" enough, given you're using a Debian packaged kernel
and all. Not so different from the mkimage-style support for u-boot.

It is a frustrating that there are so many ways to boot arm systems...
but that is the reality out there actually implemented in hardware...


live well,
vagrant

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZE7sHwAKCRDcUY/If5cW qltjAP9sioy7ncMqodbRAkbsU+PTZpqF6V8DOrOeQjJ5CjW91AD/fEh8QbX1YKuu Nv+JMV9vafbEdASnLZp7phAXZexLlwo=
=uYH2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.arm

Dear Vagrant,

Appreciate your response!

On Sun, Apr 30, 2023 at 3:40 PM Vagrant Cascadian <[email protected]> wrote:

On 2023-04-30, Roger Shimizu wrote:

I'm trying to support an ARM based RB3 / DB845c [1] dev-board with android-style boot image to flash-kernel.

...

My question is:
- Currently flash-kernel is mainly u-boot based, is it proper to add "mkbootimg" based devices?

My main worry here is investing too much in flash-kernel, rather than replacing it... both require possibly significant effort, and I wonder
if that effort would not be better spent writing a more modular
replacement for flash-kernel? That said, I have not mustered the energy
to do this myself...

To some degree, I have been the de-facto maintainer for flash-kernel,
but I am hesitant to make significant changes to it... it is not easy
code to read...

Yes, I agree that flash-kernel is difficult to understand and maintain.
But we have to use it (at least before any alternative appears), and extend it a bit to adapt to our recent needs.

- Does mkbootimg need to support udeb in order to support D-I for this dev-board in the future?

I *think* that the udeb (indirectly?) calls flash-kernel inside the
chroot... so I am not sure that would be necessary. There's no
"u-boot-tools" udeb, and many boards use mkimage from "u-boot-tools".

Thanks for the info!
I'll dig it deeper.

gzip -c9 /boot/vmlinuz-6.1.0-8-arm64 > vmlinuz.gz
cat vmlinuz.gz /usr/lib/linux-image-6.1.0-8-arm64/qcom/sdm845-db845c.dtb > Image
mkbootimg \
--kernel Image \
--ramdisk /boot/initrd.img-6.1.0-8-arm64 \
--output boot.img \
--pagesize "4096" \
--base "0x80000000" \
--kernel_offset "0x8000" \
--ramdisk_offset "0x1000000" \
--tags_offset "0x100" \
--cmdline "root=PARTLABEL=rootfs console=tty0
console=ttyMSM0,115200n8 clk_ignore_unused pd_ignore_unused"

That seems "simple" enough, given you're using a Debian packaged kernel
and all. Not so different from the mkimage-style support for u-boot.

I have some more good news.
I found mkbootimg can be replaced by abootimg command, which is
already supported by flash-kernel.
And I already try to patch flash-kernel to work with the board.
The only issue is we need to gzip the debian kernel, which is #831003
[1], and we already have two
patches [2][3] for the ticket.

I'm not sure which patch do you prefer, since they existed for so
long, but still not merged yet.
I tried the 2nd patch [3], and found it needs slightly update,
otherwise it cannot be used.
I posted the update on the MR.
My patch already works well with this path.

[1] https://bugs.debian.org/831003
[2] https://bugs.debian.org/831003#10
[3] https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/15

If you prefer the 1st patch, which is simpler and straightforward,
just let me know, and I can test it and
make adaptations if necessary.

It is a frustrating that there are so many ways to boot arm systems...
but that is the reality out there actually implemented in hardware...

live well,
vagrant

Variety always costs.
I just hope that could be limited to an acceptable level.

Cheers,
Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)