Bug#1016963: Help with testing u-boot!
On 2022-12-28, Rick Thomas wrote: > A Cubox-i running Debian bullseye (11.6). According to versions> It has "u-boot-tools" (version 2021.01+dfsg-5) installed, > but none of the u-boot- 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... Installing the packge does not install u-boot to the boot media, it is a manual process, as it can be board-specific. > 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 signature.asc Description: PGP signature
Bug#1016963: Help with testing u-boot!
On Thursday, 29 December 2022 04:33:51 CET Rick Thomas wrote: > 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. The main difference with your other Cubox-i output is the 'SPL' part. I have no clue about Cubox-i, but on Rockchip/Pine64 devices you (often) can boot from SPI, eMMC and SDcard and its preference is also in that order. So if you have u-boot on SPI (flash), then it'll use that (if it also preferences SPI above others). Which likely means that you could also completely remove the u-boot packages and that has no effect on your ability to boot the device. If you want to try newer u-boot versions, then you need to find out how to either update u-boot in SPI or how to clear the contents of SPI, so it would 'fall back' on u-boot found somewhere else, like SDcard. HTH signature.asc Description: This is a digitally signed message part.
Bug#1016963: Help with testing u-boot!
On 2022-12-29, Diederik de Haas wrote: > On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote: >> 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 signature.asc Description: PGP signature
Bug#1016963: Help with testing u-boot!
Hi. On Wed, Dec 28, 2022 at 03:21:05PM -0800, Vagrant Cascadian wrote: > On 2022-12-22, Vagrant Cascadian wrote: > > On 2022-08-20, Vagrant Cascadian wrote: > >> On 2022-08-10, Vagrant Cascadian wrote: > >>> This bug is just to delay migration to testing while more platforms get > >>> tested. If you have a relevent board, please consider testing and > >>> reporting the status: > >>> > >>> 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
Bug#1016963: Help with testing u-boot!
Here's another Cubox-i. This one's running Bookworm. shows a surprising number of u-boot- packages installed, ( = 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. Should I try installing the "22.04" version in the firmware? If so, are there directions for doing that available somewhere? HTH Rick On Wed, Dec 28, 2022, at 3:21 PM, Vagrant Cascadian wrote: > On 2022-12-22, Vagrant Cascadian wrote: >> On 2022-08-20, Vagrant Cascadian wrote: >>> On 2022-08-10, Vagrant Cascadian wrote: This bug is just to delay migration to testing while more platforms get tested. If you have a relevent board, please consider testing and reporting the status: 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 1016...@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 > > Attachments: > * signature.asc
Bug#1016963: Help with testing u-boot!
A Cubox-i running Debian bullseye (11.6). According to It has "u-boot-tools" (version 2021.01+dfsg-5) installed, but none of the u-boot- 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... 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 On Wed, Dec 28, 2022, at 3:21 PM, Vagrant Cascadian wrote: > On 2022-12-22, Vagrant Cascadian wrote: >> On 2022-08-20, Vagrant Cascadian wrote: >>> On 2022-08-10, Vagrant Cascadian wrote: This bug is just to delay migration to testing while more platforms get tested. If you have a relevent board, please consider testing and reporting the status: 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 1016...@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 > > Attachments: > * signature.asc
Bug#1016963: Help with testing u-boot!
Raspberry Pi 4B (8GB) running bullseye, but does not seem to have any version of u-boot installed. Weird? Running 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
Bug#1016963: Help with testing u-boot!
On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote: > 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 signature.asc Description: This is a digitally signed message part.
Bug#1016963: Help with testing u-boot!
On 2022-12-22, Vagrant Cascadian wrote: > On 2022-08-20, Vagrant Cascadian wrote: >> On 2022-08-10, Vagrant Cascadian wrote: >>> This bug is just to delay migration to testing while more platforms get >>> tested. If you have a relevent board, please consider testing and >>> reporting the status: >>> >>> 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 1016...@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 signature.asc Description: PGP signature
