Bug#1016963: Help with testing u-boot!

[Vagrant Cascadian]

This bug is just to delay migration to testing while more platforms get
tested. If you have a relevent board, please consider testing and
https://wiki.debian.org/U-boot/Status

I have not received many test results for current or even remotely
recent u-boot platforms in Debian, and u-boot has been blocked from
migration to testing partly because of this.

As the bookworm freeze approaches, this is getting to be... worrysome!

If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
to ***@bugs.debian.org with a positive confirmation...

...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.

# arm64
khadas-vim
khadas-vim2
libretech-cc
nanopi-k2
odroid-c2
odroid-n2
mvebu_espressobin-88f3720
dragonboard410c
dragonboard820c
firefly-rk3399
nanopc-t4-rk3399
nanopi-neo4-rk3399
pinebook-pro-rk3399
puma-rk3399
roc-pc-rk3399
rock-pi-4-rk3399
rock-pi-e-rk3328
rock64-rk3328
rockpro64-rk3399
rpi_3
rpi_4
rpi_arm64
a64-olinuxino
a64-olinuxino-emmc
nanopi_neo2
nanopi_neo_plus2
orangepi_one_plus
orangepi_zero_plus2
pine64-lts
pine64_plus
pinebook
pinephone
pinetab
sopine_baseboard
teres_i
p2371-2180

# armel
dockstar
dreamplug
guruplug
sheevaplug
rpi
rpi_0_w

# armhf
arndale
odroid
odroid-xu3
colibri_imx6
dh_imx6
mx53loco
mx6cuboxi
mx6qsabrelite
nitrogen6q
novena
novena-rawsd
udoo
usbarmory
wandboard
am335x_boneblack
am335x_evm
am57xx_evm
dra7xx_evm
igep00x0
nokia_rx51
omap3_beagle
omap4_panda
firefly-rk3288
rpi_2
rpi_3_32b
rpi_4_32b
stm32mp157c-dk2
A10-OLinuXino-Lime
A10s-OLinuXino-M
A20-OLinuXino-Lime
A20-OLinuXino-Lime2
A20-OLinuXino-Lime2-eMMC
A20-OLinuXino_MICRO
A20-OLinuXino_MICRO-eMMC
A20-Olimex-SOM-EVB
Bananapi
Bananapi_M2_Ultra
Bananapro
CHIP
Cubieboard
Cubieboard2
Cubieboard4
Cubietruck
Cubietruck_plus
Lamobo_R1
Linksprite_pcDuino
Linksprite_pcDuino3
Mini-X
Sinovoip_BPI_M3
bananapi_m2_berry
nanopi_neo
nanopi_neo_air
orangepi_plus
orangepi_zero
jetson-tk1


Thanks!


live well,
vagrant

[Rick Thomas]

Raspberry Pi 4B (8GB) running bullseye, but does not seem to have any version of u-boot installed. Weird?
Running <aptitude versions '?name(u-boot)'> tells me that the following (among lots of others) versions are available. Should I install one of them and see what happens?

Package u-boot-rpi:
p 2021.01+dfsg-5 stable 500

Package u-boot-rpi:armhf:
p 2021.01+dfsg-5 stable 500

HTH
Rick

[Rick Thomas]

A Cubox-i running Debian bullseye (11.6). According to <aptitude versions> It has "u-boot-tools" (version 2021.01+dfsg-5) installed, but none of the u-boot-<arch> packages installed.

If I reboot it and watch the serial console, I see it showing "U-boot 2021.01-dfsg-5" so that version must have gotten into the firmware somehow without telling Linux about it... <shrug?>
Other info that might be helpful that shows with the reboot is
CPU: Freescale i.MX6Q rev 1.3
Board: MX6 Cubox-i

HTH,
Rick

Post by Vagrant Cascadian

This bug is just to delay migration to testing while more platforms get
tested. If you have a relevent board, please consider testing and
https://wiki.debian.org/U-boot/Status

I have not received many test results for current or even remotely
recent u-boot platforms in Debian, and u-boot has been blocked from
migration to testing partly because of this.
As the bookworm freeze approaches, this is getting to be... worrysome!
If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.
# arm64
khadas-vim
khadas-vim2
libretech-cc
nanopi-k2
odroid-c2
odroid-n2
mvebu_espressobin-88f3720
dragonboard410c
dragonboard820c
firefly-rk3399
nanopc-t4-rk3399
nanopi-neo4-rk3399
pinebook-pro-rk3399
puma-rk3399
roc-pc-rk3399
rock-pi-4-rk3399
rock-pi-e-rk3328
rock64-rk3328
rockpro64-rk3399
rpi_3
rpi_4
rpi_arm64
a64-olinuxino
a64-olinuxino-emmc
nanopi_neo2
nanopi_neo_plus2
orangepi_one_plus
orangepi_zero_plus2
pine64-lts
pine64_plus
pinebook
pinephone
pinetab
sopine_baseboard
teres_i
p2371-2180
# armel
dockstar
dreamplug
guruplug
sheevaplug
rpi
rpi_0_w
# armhf
arndale
odroid
odroid-xu3
colibri_imx6
dh_imx6
mx53loco
mx6cuboxi
mx6qsabrelite
nitrogen6q
novena
novena-rawsd
udoo
usbarmory
wandboard
am335x_boneblack
am335x_evm
am57xx_evm
dra7xx_evm
igep00x0
nokia_rx51
omap3_beagle
omap4_panda
firefly-rk3288
rpi_2
rpi_3_32b
rpi_4_32b
stm32mp157c-dk2
A10-OLinuXino-Lime
A10s-OLinuXino-M
A20-OLinuXino-Lime
A20-OLinuXino-Lime2
A20-OLinuXino-Lime2-eMMC
A20-OLinuXino_MICRO
A20-OLinuXino_MICRO-eMMC
A20-Olimex-SOM-EVB
Bananapi
Bananapi_M2_Ultra
Bananapro
CHIP
Cubieboard
Cubieboard2
Cubieboard4
Cubietruck
Cubietruck_plus
Lamobo_R1
Linksprite_pcDuino
Linksprite_pcDuino3
Mini-X
Sinovoip_BPI_M3
bananapi_m2_berry
nanopi_neo
nanopi_neo_air
orangepi_plus
orangepi_zero
jetson-tk1
Thanks!
live well,
vagrant
* signature.asc

[Vagrant Cascadian]

Post by Rick Thomas
A Cubox-i running Debian bullseye (11.6). According to <aptitude
versions> It has "u-boot-tools" (version 2021.01+dfsg-5) installed,
but none of the u-boot-<arch> packages installed.
If I reboot it and watch the serial console, I see it showing "U-boot
2021.01-dfsg-5" so that version must have gotten into the firmware
somehow without telling Linux about it... <shrug?>

Installing the packge does not install u-boot to the boot media, it is a
manual process, as it can be board-specific.

Post by Rick Thomas
Other info that might be helpful that shows with the reboot is
CPU: Freescale i.MX6Q rev 1.3
Board: MX6 Cubox-i

For Cubox-i install u-boot-imx and see
/usr/share/doc/u-boot-imx/README.Debian for instructions on how to
actually install the boot firmware onto microSD.


live well,
vagrant

[Rick Thomas]

Here's another Cubox-i. This one's running Bookworm.
<aptitude versions '?name(u-boot)'> shows a surprising number of u-boot-<arch> packages installed, (<arch> = exynos, imx, omap, sunxi) as well as plain "u-boot". All of them are version 2022.04+dfsg-2+b1.

Rebooting while watching the serial console output says "U-Boot SPL 2016.05-rc2+dfsg0~20160423~1-1 (Apr 24 2016 - 04:24:21)" So the firmware does not correspond to what aptitude says. <hmmm...>

Should I try installing the "22.04" version in the firmware? If so, are there directions for doing that available somewhere?

HTH
Rick

Post by Vagrant Cascadian

This bug is just to delay migration to testing while more platforms get
tested. If you have a relevent board, please consider testing and
https://wiki.debian.org/U-boot/Status

I have not received many test results for current or even remotely
recent u-boot platforms in Debian, and u-boot has been blocked from
migration to testing partly because of this.
As the bookworm freeze approaches, this is getting to be... worrysome!
If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.
# arm64
khadas-vim
khadas-vim2
libretech-cc
nanopi-k2
odroid-c2
odroid-n2
mvebu_espressobin-88f3720
dragonboard410c
dragonboard820c
firefly-rk3399
nanopc-t4-rk3399
nanopi-neo4-rk3399
pinebook-pro-rk3399
puma-rk3399
roc-pc-rk3399
rock-pi-4-rk3399
rock-pi-e-rk3328
rock64-rk3328
rockpro64-rk3399
rpi_3
rpi_4
rpi_arm64
a64-olinuxino
a64-olinuxino-emmc
nanopi_neo2
nanopi_neo_plus2
orangepi_one_plus
orangepi_zero_plus2
pine64-lts
pine64_plus
pinebook
pinephone
pinetab
sopine_baseboard
teres_i
p2371-2180
# armel
dockstar
dreamplug
guruplug
sheevaplug
rpi
rpi_0_w
# armhf
arndale
odroid
odroid-xu3
colibri_imx6
dh_imx6
mx53loco
mx6cuboxi
mx6qsabrelite
nitrogen6q
novena
novena-rawsd
udoo
usbarmory
wandboard
am335x_boneblack
am335x_evm
am57xx_evm
dra7xx_evm
igep00x0
nokia_rx51
omap3_beagle
omap4_panda
firefly-rk3288
rpi_2
rpi_3_32b
rpi_4_32b
stm32mp157c-dk2
A10-OLinuXino-Lime
A10s-OLinuXino-M
A20-OLinuXino-Lime
A20-OLinuXino-Lime2
A20-OLinuXino-Lime2-eMMC
A20-OLinuXino_MICRO
A20-OLinuXino_MICRO-eMMC
A20-Olimex-SOM-EVB
Bananapi
Bananapi_M2_Ultra
Bananapro
CHIP
Cubieboard
Cubieboard2
Cubieboard4
Cubietruck
Cubietruck_plus
Lamobo_R1
Linksprite_pcDuino
Linksprite_pcDuino3
Mini-X
Sinovoip_BPI_M3
bananapi_m2_berry
nanopi_neo
nanopi_neo_air
orangepi_plus
orangepi_zero
jetson-tk1
Thanks!
live well,
vagrant
* signature.asc

[Reco]

Hi.

Post by Vagrant Cascadian

This bug is just to delay migration to testing while more platforms get
tested. If you have a relevent board, please consider testing and
https://wiki.debian.org/U-boot/Status

I have not received many test results for current or even remotely
recent u-boot platforms in Debian, and u-boot has been blocked from
migration to testing partly because of this.
As the bookworm freeze approaches, this is getting to be... worrysome!

That Ordoid N2 board that I had was damaged about year ago.
I have not procured a replacement to it since then.

So I cannot test u-boot on Odroid N2 in the foreseeable future.

Reco

[gene heskett]

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)
# arm64
...
rock64-rk3328

I don't recall ever having issues with u-boot on my Rock64's, so for me
2022.04 - 2022.10 surely work. I'll try the experimental version soon.
I generate my own images for Rock64 and that uses 'dd ... seek=' of
idbloader.img and u-boot.itb from the u-boot-rockchip package.
I have been doing that since 2021-03, so it's very likely that I haven't seen
an issue since then.
HTH,
Diederik

Humm, I thought I'd see if dfu-util-0.11 worked so I just pulled the
arm64 daily netinstall iso and put it on a u-sd card. But a bpi m5 makes
no attempt to boot it, green led remains dim forever. I can mount it in
my reader, a iso-9660 and its not a u-boot, its grub. So which of the
arm64 iso's is u-booter?

Thanks all.

Cheers, Gene Heskett.

[Vagrant Cascadian]

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)

...

But a bpi m5 makes no attempt to boot it green led remains dim
forever.

Presuming you mean bananapi-m5, it is not enabled yet in the Debian
packages of u-boot...

I can mount it in my reader, a iso-9660 and its not a u-boot, its
grub. So which of the arm64 iso's is u-booter?

None of the debian-installer iso images contain u-boot. They only work
with systems with EFI firmware installed (which, somewhat confusingly,
u-boot could provide in some cases).

U-boot is board-specific, so a single image will almost never support
booting more than a very small number of systems.

Supported debian-installer platforms that have at some point in history
been tested to work are:

https://d-i.debian.org/daily-images/arm64/daily/u-boot/

There are SD card images you can build, see the
README.concatenatable_images at:

https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

You can typically using the firmware.none.img and manually add
u-boot. Which offsets to write to are board-specific, though there are
often common patterns for various board families (e.g. sunxi SoCs mostly
have the same offsets, rockchip SoC mostly use same offsets)...


The bananapi-m5 appears to be amlogic based, and there are a few other
amlogic based boards enabled in Debian's u-boot-amlogic package, but
unfortunately they require quite a few extra hoops to jump through that
make it difficult for Debian to ship images that you can just write to
boot media.

There are hints at fixing part of the problem at
u-boot.git/doc/board/amlogic/libretech-cc.rst:

Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
source code. Should you prefer to avoid that, there are open source reverse
engineered versions available:

1. gxlimg <https://github.com/repk/gxlimg>, which comes with a handy
Makefile that automates the whole process.
2. meson-tools <https://github.com/afaerber/meson-tools>

However, these community-developed alternatives are not endorsed by or
supported by Amlogic.


live well,
vagrant

[gene heskett]

Post by Vagrant Cascadian

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)

...

But a bpi m5 makes no attempt to boot it green led remains dim
forever.

Presuming you mean bananapi-m5, it is not enabled yet in the Debian
packages of u-boot...

I can mount it in my reader, a iso-9660 and its not a u-boot, its
grub. So which of the arm64 iso's is u-booter?

None of the debian-installer iso images contain u-boot. They only work
with systems with EFI firmware installed (which, somewhat confusingly,
u-boot could provide in some cases).
U-boot is board-specific, so a single image will almost never support
booting more than a very small number of systems.
Supported debian-installer platforms that have at some point in history
https://d-i.debian.org/daily-images/arm64/daily/u-boot/
There are SD card images you can build, see the
https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
You can typically using the firmware.none.img and manually add
u-boot. Which offsets to write to are board-specific, though there are
often common patterns for various board families (e.g. sunxi SoCs mostly
have the same offsets, rockchip SoC mostly use same offsets)...
The bananapi-m5 appears to be amlogic based, and there are a few other
amlogic based boards enabled in Debian's u-boot-amlogic package, but
unfortunately they require quite a few extra hoops to jump through that
make it difficult for Debian to ship images that you can just write to
boot media.
There are hints at fixing part of the problem at
Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
source code. Should you prefer to avoid that, there are open source reverse
1. gxlimg <https://github.com/repk/gxlimg>, which comes with a handy
Makefile that automates the whole process.
2. meson-tools <https://github.com/afaerber/meson-tools>
However, these community-developed alternatives are not endorsed by or
supported by Amlogic.
live well,
vagrant

You too. I did find out the dfu problem is the robin nano boards, I
cloned the gitub version 0.11, built and installed it on the bpi5 only
to get the exact same failure message, finding in an old old klipper
config that dfu didn't work on robin nano boards but they also have a
recipe to upload to a nano. But that build is for the wrong mcu.

but the klipper board files are even older than Marlins so I'm still
screwed.

Thanks Vagrant.

Cheers, Gene Heskett.

[Vagrant Cascadian]

debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
and experimental (2023.01-rc*)
# arm64
...
rock64-rk3328

I don't recall ever having issues with u-boot on my Rock64's, so for me
2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I have been testing that one, but thanks for the extra testing!

I generate my own images for Rock64 and that uses 'dd ... seek=' of
idbloader.img and u-boot.itb from the u-boot-rockchip package.
I have been doing that since 2021-03, so it's very likely that I haven't seen
an issue since then.

u-boot-rockchip also includes a u-boot-install-rockchip script which
might simplify the process for you. :)


live well,
vagrant