Re: Bug#782574: installation-reports: d-i does not boot on beaglebone black
Hi everybody,
My 5 ¢ :
Le 03/06/2015 03:16, Vagrant Cascadian a écrit :
On 2015-05-27, François-Régis wrote:
Le 27/05/2015 20:36, Vagrant Cascadian a écrit :
Here's a stab at some text and instructions:
Booting BeagleBone Black
The u-boot version shipped with Debian Jessie does not work out of the
box with debian-installer on the BeagleBone Black. The following
workaround should enable booting by setting some environment variables
at the u-boot prompt, using the appropriate SD-card-images from Jessie
debian-installer:
You will need a serial console and press a key before u-boot tries to
start d-i.
Set the fdt file:
U-Boot# run findfdt
U-Boot# printenv fdtfile
fdtfile=am335x-boneblack.dtb
If it doesn't set the fdt file correctly, set it manually:
U-Boot# setenv fdtfile am335x-boneblack.dtb
Set a few compatibility variables:
U-Boot# setenv devnum 0
U-Boot# setenv bootpart 1
U-Boot# setenv devtype mmc
U-Boot# setenv boot_targets mmc0
Ensure that the console variable is set appropriately:
U-Boot# printenv console
console=ttyO0,115200n8
Load the boot script manually:
U-Boot# load ${devtype} ${devnum}:${bootpart} ${loadaddr} ${script}
U-Boot# source ${loadaddr}
If everything went well, it should load the kernel, initrd, device-tree,
and boot into debian-installer...
If there's an old u-boot version on the eMMC and these instructions
don't work, it may require pressing the boot button (near the micro-SD
slot) to load u-boot off of the micro-SD card.
--
François-Régis
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/556f540b.3060...@miradou.com
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Hi folks, Vagrant Cascadian vagr...@debian.org (2015-05-27): Seems like we've missed the chance to resolve this for Jessie's first point release, but perhaps we can make it for the second point release? Sorry for not having been able to keep a close eye on this… Let's try and make that into 8.2 indeed. You can start filing p-u bug reports already, x-d-cc'ing debian-boot@ and possibly me as well, just to make sure. I don't see anything mentioned in the errata yet: https://www.debian.org/releases/stable/debian-installer/#errata Not sure what the process is to update that, but I'd be happy to work on some text for it. If nobody picks the “update the docs” ball, I'll try and get that part done. Flash-kernel in unstable has the needed changes and u-boot in unstable has the needed changes, although I think it would be better to go with the smaller patch I had proposed earlier rather than backporting the entire distro_bootcmd stack... ACK, small is good (when feasible). Now that USB support is working on the BBB with the kernel in jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive platform for running Debian on, so it would be nice to get d-i support working out of the box... Indeed, sorry again. Mraw, KiBi. signature.asc Description: Digital signature
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On 2015-05-27, François-Régis wrote:
Le 27/05/2015 20:36, Vagrant Cascadian a écrit :
I don't see anything mentioned in the errata yet:
https://www.debian.org/releases/stable/debian-installer/#errata
Not sure what the process is to update that, but I'd be happy to work on
some text for it.
I was not very pushy to make this mentioned in the errata giving the
fact that the most popular way to install debian on BBB is to use
readymade disk images and not d-i. That said I'd like to help on
documenting.
Here's a stab at some text and instructions:
Booting BeagleBone Black
The u-boot version shipped with Debian Jessie does not work out of the
box with debian-installer on the BeagleBone Black. The following
workaround should enable booting by setting some environment variables
at the u-boot prompt, using the appropriate SD-card-images from Jessie
debian-installer:
Set the fdt file:
U-Boot# run findfdt
U-Boot# printenv fdtfile
fdtfile=am335x-boneblack.dtb
If it doesn't set the fdt file correctly, set it manually:
U-Boot# setenv fdtfile am335x-boneblack.dtb
Set a few compatibility variables:
U-Boot# setenv devnum 0
U-Boot# setenv bootpart 1
U-Boot# setenv devtype mmc
U-Boot# setenv boot_targets mmc0
Ensure that the console variable is set appropriately:
U-Boot# printenv console
console=ttyO0,115200n8
Load the boot script manually:
U-Boot# load ${devtype} ${devnum}:${bootpart} ${loadaddr} ${script}
U-Boot# source ${loadaddr}
If everything went well, it should load the kernel, initrd, device-tree,
and boot into debian-installer...
If there's an old u-boot version on the eMMC and these instructions
don't work, it may require pressing the boot button (near the micro-SD
slot) to load u-boot off of the micro-SD card.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On Thu, May 28, 2015 at 01:21:52AM +0200, François-Régis wrote: Le 27/05/2015 22:20, Lennart Sorensen a écrit : On Wed, May 27, 2015 at 11:36:09AM -0700, Vagrant Cascadian wrote: I am curious though: With the am3359-evmsk board I see no network traffic with gigabit link and the 3.16 (or 4.0) kernel, but I do see traffic at 100Mbit link speed. Does anyone with a beaglebone see the same behaviour? Using the TI sdk kernel does work at gigabit speed, so the hardware seems fine. AFAIK beaglebone black has only 10/100 ethernet link [1] so it's hard to watch the same behaviour. [1] http://elinux.org/Beagleboard:BeagleBoneBlack#BeagleBone_Black_Features Hmm, odd given I thought the CPU did gigabit. Doing a check of the dtb files I see that yes the CPU can do gigabit, but the phy used on the beaglebone boards is 100Mbit only, so the bug could never affect them. So only the few boards with the Am335x that have gigabit in use could see such a bug. So not an issue really. That's good. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150529202747.gn6...@csclub.uwaterloo.ca
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On 2015-04-15, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-04-15): On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: I've tested that it boots the armhf daily hd-media installer and boots an installed system. I could upload a new version of u-boot if it's deemed worth it; otherwise we'll just need more complicated instructions for manually loading the installer on d-i. FWIW, The netboot media via tftp works without any changes. ... As the deadline for d-i-relevant changes is Friday, the question is what to do now. AFAICS due to the necessity to change the BBB boot script in flash-kernel when the patch is applied to u-boot, both flash-kernel and u-boot would have to enter Jessie in lockstep. As there is not enough time for regular migration to Jessie, the release team would have to urgent both packages in addition to an unblock to keep the deadline. The involved DDs are in vastly different timezones, which makes all this even more problematic. As stated above, I probably won't be able to take care of flash-kernel in time, so unless Ian would like to handle that, I do not see a a realistic chance to get this solved for Jessie. ... So I've been thinking about this for a while and I'm not too happy about possibly rushing these changes at this point. What could be considered instead is having these changes staged into unstable, let them migrate to testing/stretch when the freeze is lifted, and possibly backport them in to the jessie first point release. A workaround can be documented in the D-I Jessie RC3 errata. Seems like we've missed the chance to resolve this for Jessie's first point release, but perhaps we can make it for the second point release? I don't see anything mentioned in the errata yet: https://www.debian.org/releases/stable/debian-installer/#errata Not sure what the process is to update that, but I'd be happy to work on some text for it. Flash-kernel in unstable has the needed changes and u-boot in unstable has the needed changes, although I think it would be better to go with the smaller patch I had proposed earlier rather than backporting the entire distro_bootcmd stack... Now that USB support is working on the BBB with the kernel in jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive platform for running Debian on, so it would be nice to get d-i support working out of the box... live well, vagrant signature.asc Description: PGP signature
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On Wed, May 27, 2015 at 11:36:09AM -0700, Vagrant Cascadian wrote: Seems like we've missed the chance to resolve this for Jessie's first point release, but perhaps we can make it for the second point release? I don't see anything mentioned in the errata yet: https://www.debian.org/releases/stable/debian-installer/#errata Not sure what the process is to update that, but I'd be happy to work on some text for it. Flash-kernel in unstable has the needed changes and u-boot in unstable has the needed changes, although I think it would be better to go with the smaller patch I had proposed earlier rather than backporting the entire distro_bootcmd stack... Now that USB support is working on the BBB with the kernel in jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive platform for running Debian on, so it would be nice to get d-i support working out of the box... Yay. I am curious though: With the am3359-evmsk board I see no network traffic with gigabit link and the 3.16 (or 4.0) kernel, but I do see traffic at 100Mbit link speed. Does anyone with a beaglebone see the same behaviour? Using the TI sdk kernel does work at gigabit speed, so the hardware seems fine. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150527202005.gg6...@csclub.uwaterloo.ca
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On 2015-05-27, François-Régis wrote: Le 27/05/2015 20:36, Vagrant Cascadian a écrit : On 2015-04-15, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-04-15): On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: So I've been thinking about this for a while and I'm not too happy about possibly rushing these changes at this point. What could be considered instead is having these changes staged into unstable, let them migrate to testing/stretch when the freeze is lifted, and possibly backport them in to the jessie first point release. A workaround can be documented in the D-I Jessie RC3 errata. Seems like we've missed the chance to resolve this for Jessie's first point release, but perhaps we can make it for the second point release? I don't see anything mentioned in the errata yet: https://www.debian.org/releases/stable/debian-installer/#errata Not sure what the process is to update that, but I'd be happy to work on some text for it. I was not very pushy to make this mentioned in the errata giving the fact that the most popular way to install debian on BBB is to use readymade disk images and not d-i. If it's hard to install using d-i, it'll stay that way, which sounds like a bug worth fixing to me :) That said I'd like to help on documenting. Good. Flash-kernel in unstable has the needed changes and u-boot in unstable has the needed changes, although I think it would be better to go with the smaller patch I had proposed earlier rather than backporting the entire distro_bootcmd stack... Now that USB support is working on the BBB with the kernel in jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive platform for running Debian on, so it would be nice to get d-i support working out of the box... Definitely yes, with flash-kernel, u-boot and kernel having a good coverage of bbb hardware, d-i could be the prefered way to use debian on bbb. (Vagrant:could you give me a pointer on the kernel supporting usb ?) It was fixed in linux 3.16.7-ckt11-1 (as well as the 4.x version currently in sid): https://bugs.debian.org/773400 It's currently available in the jessie-proposed-updates repository, and I presume will be released with the stable point release coming up shortly: https://wiki.debian.org/StableProposedUpdates live well, vagrant signature.asc Description: PGP signature
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Hi Vagrant, Hi Cyril, Hi all, Le 27/05/2015 20:36, Vagrant Cascadian a écrit : On 2015-04-15, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-04-15): On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: So I've been thinking about this for a while and I'm not too happy about possibly rushing these changes at this point. What could be considered instead is having these changes staged into unstable, let them migrate to testing/stretch when the freeze is lifted, and possibly backport them in to the jessie first point release. A workaround can be documented in the D-I Jessie RC3 errata. Seems like we've missed the chance to resolve this for Jessie's first point release, but perhaps we can make it for the second point release? I don't see anything mentioned in the errata yet: https://www.debian.org/releases/stable/debian-installer/#errata Not sure what the process is to update that, but I'd be happy to work on some text for it. I was not very pushy to make this mentioned in the errata giving the fact that the most popular way to install debian on BBB is to use readymade disk images and not d-i. That said I'd like to help on documenting. Flash-kernel in unstable has the needed changes and u-boot in unstable has the needed changes, although I think it would be better to go with the smaller patch I had proposed earlier rather than backporting the entire distro_bootcmd stack... Now that USB support is working on the BBB with the kernel in jessie-proposed-updates(Yay!), BeagleBone Black is a more attractive platform for running Debian on, so it would be nice to get d-i support working out of the box... Definitely yes, with flash-kernel, u-boot and kernel having a good coverage of bbb hardware, d-i could be the prefered way to use debian on bbb. (Vagrant:could you give me a pointer on the kernel supporting usb ?) -- François-Régis signature.asc Description: OpenPGP digital signature
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Le 27/05/2015 22:20, Lennart Sorensen a écrit : On Wed, May 27, 2015 at 11:36:09AM -0700, Vagrant Cascadian wrote: I am curious though: With the am3359-evmsk board I see no network traffic with gigabit link and the 3.16 (or 4.0) kernel, but I do see traffic at 100Mbit link speed. Does anyone with a beaglebone see the same behaviour? Using the TI sdk kernel does work at gigabit speed, so the hardware seems fine. AFAIK beaglebone black has only 10/100 ethernet link [1] so it's hard to watch the same behaviour. [1] http://elinux.org/Beagleboard:BeagleBoneBlack#BeagleBone_Black_Features -- François-Régis -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55665190.6070...@miradou.com
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On Wed, 2015-04-15 at 23:39 +0200, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-04-15): On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: Did some troubleshooting (far more than I expected, now I remember why I hadn't already done this for BBB), and came up with a patch for u-boot that makes it work with d-i by emulating some distro bootcmd variables (similar to the patch for wandboard), and a small patch to flash kernel to support the change in how the bootpart variable is used. Since Karsten mentions both have to reach jessie in lockstep, I'm wondering whether there should be a Breaks: somewhere to avoid some breakages in case of a partial update. I've tested that it boots the armhf daily hd-media installer and boots an installed system. I could upload a new version of u-boot if it's deemed worth it; otherwise we'll just need more complicated instructions for manually loading the installer on d-i. FWIW, The netboot media via tftp works without any changes. If the user ever used u-boot's saveenv command, it may take considerable effort resetting the environment using env default -a followed by manually setting board_name, findfdt and/or fdtfile variables so that it detects the correct .dtb. I didn't have consistant success zeroing out the boot device, but in theory that should work too. I had hoped to be able to spend some more time on the issue today, but things didn't work out as planned and as things are looking curently, I probably won't be able to dedicate time to it tomorrow as well. As the deadline for d-i-relevant changes is Friday, the question is what to do now. AFAICS due to the necessity to change the BBB boot script in flash-kernel when the patch is applied to u-boot, both flash-kernel and u-boot would have to enter Jessie in lockstep. As there is not enough time for regular migration to Jessie, the release team would have to urgent both packages in addition to an unblock to keep the deadline. The involved DDs are in vastly different timezones, which makes all this even more problematic. As stated above, I probably won't be able to take care of flash-kernel in time, so unless Ian would like to handle that, I do not see a a realistic chance to get this solved for Jessie. Ian, what is your take on the issue? So I've been thinking about this for a while and I'm not too happy about possibly rushing these changes at this point. What could be considered instead is having these changes staged into unstable, let them migrate to testing/stretch when the freeze is lifted, and possibly backport them in to the jessie first point release. A workaround can be documented in the D-I Jessie RC3 errata. Would that seem reasonable to all people involved? Yes, IIRC from the thread the workaround is pretty simple, certainly in comparison with the scope of the proposed changes. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1429168841.5660.42.ca...@debian.org
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Le 16/04/2015 09:20, Ian Campbell a écrit : On Wed, 2015-04-15 at 23:39 +0200, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-04-15): On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: Did some troubleshooting (far more than I expected, now I remember why I hadn't already done this for BBB), and came up with a patch for u-boot that makes it work with d-i by emulating some distro bootcmd variables (similar to the patch for wandboard), and a small patch to flash kernel to support the change in how the bootpart variable is used. Since Karsten mentions both have to reach jessie in lockstep, I'm wondering whether there should be a Breaks: somewhere to avoid some breakages in case of a partial update. I've tested that it boots the armhf daily hd-media installer and boots an installed system. I could upload a new version of u-boot if it's deemed worth it; otherwise we'll just need more complicated instructions for manually loading the installer on d-i. FWIW, The netboot media via tftp works without any changes. If the user ever used u-boot's saveenv command, it may take considerable effort resetting the environment using env default -a followed by manually setting board_name, findfdt and/or fdtfile variables so that it detects the correct .dtb. I didn't have consistant success zeroing out the boot device, but in theory that should work too. I had hoped to be able to spend some more time on the issue today, but things didn't work out as planned and as things are looking curently, I probably won't be able to dedicate time to it tomorrow as well. As the deadline for d-i-relevant changes is Friday, the question is what to do now. AFAICS due to the necessity to change the BBB boot script in flash-kernel when the patch is applied to u-boot, both flash-kernel and u-boot would have to enter Jessie in lockstep. As there is not enough time for regular migration to Jessie, the release team would have to urgent both packages in addition to an unblock to keep the deadline. The involved DDs are in vastly different timezones, which makes all this even more problematic. As stated above, I probably won't be able to take care of flash-kernel in time, so unless Ian would like to handle that, I do not see a a realistic chance to get this solved for Jessie. Ian, what is your take on the issue? So I've been thinking about this for a while and I'm not too happy about possibly rushing these changes at this point. What could be considered instead is having these changes staged into unstable, let them migrate to testing/stretch when the freeze is lifted, and possibly backport them in to the jessie first point release. A workaround can be documented in the D-I Jessie RC3 errata. Would that seem reasonable to all people involved? Yes, IIRC from the thread the workaround is pretty simple, certainly in comparison with the scope of the proposed changes. As far as I'm involved, I comfirm that the workaround is simple and could easily be documented. If needed, I could help documenting the it. -- François-Régis -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55302fbf.4060...@miradou.com
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Karsten Merker mer...@debian.org (2015-04-15): On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: Did some troubleshooting (far more than I expected, now I remember why I hadn't already done this for BBB), and came up with a patch for u-boot that makes it work with d-i by emulating some distro bootcmd variables (similar to the patch for wandboard), and a small patch to flash kernel to support the change in how the bootpart variable is used. Since Karsten mentions both have to reach jessie in lockstep, I'm wondering whether there should be a Breaks: somewhere to avoid some breakages in case of a partial update. I've tested that it boots the armhf daily hd-media installer and boots an installed system. I could upload a new version of u-boot if it's deemed worth it; otherwise we'll just need more complicated instructions for manually loading the installer on d-i. FWIW, The netboot media via tftp works without any changes. If the user ever used u-boot's saveenv command, it may take considerable effort resetting the environment using env default -a followed by manually setting board_name, findfdt and/or fdtfile variables so that it detects the correct .dtb. I didn't have consistant success zeroing out the boot device, but in theory that should work too. I had hoped to be able to spend some more time on the issue today, but things didn't work out as planned and as things are looking curently, I probably won't be able to dedicate time to it tomorrow as well. As the deadline for d-i-relevant changes is Friday, the question is what to do now. AFAICS due to the necessity to change the BBB boot script in flash-kernel when the patch is applied to u-boot, both flash-kernel and u-boot would have to enter Jessie in lockstep. As there is not enough time for regular migration to Jessie, the release team would have to urgent both packages in addition to an unblock to keep the deadline. The involved DDs are in vastly different timezones, which makes all this even more problematic. As stated above, I probably won't be able to take care of flash-kernel in time, so unless Ian would like to handle that, I do not see a a realistic chance to get this solved for Jessie. Ian, what is your take on the issue? So I've been thinking about this for a while and I'm not too happy about possibly rushing these changes at this point. What could be considered instead is having these changes staged into unstable, let them migrate to testing/stretch when the freeze is lifted, and possibly backport them in to the jessie first point release. A workaround can be documented in the D-I Jessie RC3 errata. Would that seem reasonable to all people involved? Mraw, KiBi. signature.asc Description: Digital signature
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On Tue, 2015-04-14 at 13:24 +0200, Francois-Regis Vuillemin wrote: Package: installation-reports Severity: important Tags: d-i Dear Maintainer, what I've done so far : wget http://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card- images/partition.img.gz wget http://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card- images/firmware.BeagleBoneBlack.img.gz zcat firmware.BeagleBoneBlack.img.gz partition.img.gz complet_image.img dd if=complet_image.img of=/dev/mmcblk0 and boot on the bbb with that sd (I erased the internal emmc before) Here is the console log : [...] Running bootscript from mmc ... ## Executing script at 8200 Non-mainline u-boot or old-style mainline u-boot detected. This boot script uses the unified bootcmd handling of mainline u-boot =v2014.10, which is not available on your system. Please boot the installer manually. [...] It seems that this script isn't expected to work with the version of u-boot that's installed on your BBB. (Which is a shame, but maybe unavoidable.) That message could probably be improved, though. Can you find instructions for 'boot the installer manually'? What could we do to improve the documentation? Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Package: installation-reports Severity: important Tags: d-i Dear Maintainer, what I've done so far : wget http://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card- images/partition.img.gz wget http://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card- images/firmware.BeagleBoneBlack.img.gz zcat firmware.BeagleBoneBlack.img.gz partition.img.gz complet_image.img dd if=complet_image.img of=/dev/mmcblk0 and boot on the bbb with that sd (I erased the internal emmc before) Here is the console log : U-Boot SPL 2014.10+dfsg1-5 (Apr 07 2015 - 22:13:27) MMC: block number 0x100 exceeds max(0x0) MMC: block number 0x200 exceeds max(0x0) *** Error - No Valid Environment Area found Using default environment U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:13:27) Watchdog enabled I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Invalid partition 2 ** ** Invalid partition 2 ** ** Invalid partition 2 ** ** Invalid partition 2 ** ** Invalid partition 2 ** switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading /boot/boot.scr 1451 bytes read in 9 ms (157.2 KiB/s) Running bootscript from mmc ... ## Executing script at 8200 Non-mainline u-boot or old-style mainline u-boot detected. This boot script uses the unified bootcmd handling of mainline u-boot =v2014.10, which is not available on your system. Please boot the installer manually. switch to partitions #0, OK mmc1(part 0) is current device SD/MMC found on device 1 ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** switch to partitions #0, OK mmc1(part 0) is current device SD/MMC found on device 1 ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** ** No partition table - mmc 1 ** ## Error: nandboot not defined U-Boot# Thanks -- Package-specific info: Boot method: sd-card Image version: http://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/ Date: Date and time of the install Machine: Beaglebone black Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel, armhf, powerpcspe Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150414112415.8884.57824.report...@graves.miradou.com
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Hi,
Le 14/04/2015 15:51, François-Régis a écrit :
Le 14/04/2015 14:05, Ben Hutchings a écrit :
On Tue, 2015-04-14 at 13:24 +0200, Francois-Regis Vuillemin wrote:
Package: installation-reports
Severity: important
Tags: d-i
Here is the console log :
[...]
Running bootscript from mmc ...
## Executing script at 8200
Non-mainline u-boot or old-style mainline u-boot detected.
This boot script uses the unified bootcmd handling of mainline
u-boot =v2014.10, which is not available on your system.
Please boot the installer manually.
[...]
It seems that this script isn't expected to work with the version of
u-boot that's installed on your BBB. (Which is a shame, but maybe
unavoidable.) That message could probably be improved, though.
I could have misunderstood but I thought beaglebone black was loading
uboot from sd-card (or emmc), and the log shows
U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:13:27)
which seems to be the one provided with d-i ...
Can you find instructions for 'boot the installer manually'? What could
we do to improve the documentation?
U-Boot# setenv devtype mmc
U-Boot# setenv devnum 0
U-Boot# setenv bootpart 1
setenv console ttyO0,115200n8
setenv bootargs ${bootargs} console=${console}
U-Boot# load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} vmlinuz \
load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} dtbs/${fdtfile} \
load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} initrd.gz \
echo Booting the Debian installer... \
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
reading vmlinuz
3182760 bytes read in 190 ms (16 MiB/s)
reading dtbs/am335x-boneblack.dtb
29018 bytes read in 37 ms (765.6 KiB/s)
reading initrd.gz
12156022 bytes read in 704 ms (16.5 MiB/s)
Booting the Debian installer...
Kernel image @ 0x8200 [ 0x00 - 0x3090a8 ]
## Flattened Device Tree blob at 8800
Booting using the fdt blob at 0x8800
Loading Ramdisk to 8f468000, end 8c76 ... OK
Loading Device Tree to 8f45d000, end 8f467159 ... OK
Starting kernel ...
... and d-i starts on console and successfully installed jessie, uboot,
network and all !
Cheers,
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552d4f32.6010...@miradou.com
Processed: Re: Bug#782574: installation-reports: d-i does not boot on beaglebone black
Processing control commands: tags -1 +patch Bug #782574 [installation-reports] installation-reports: d-i does not boot on beaglebone black Added tag(s) patch. -- 782574: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782574 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b782574.1429062196766.transcr...@bugs.debian.org
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Control: tags -1 +patch
On 2015-04-14, Karsten Merker wrote:
On Tue, Apr 14, 2015 at 03:51:45PM +0200, François-Régis wrote:
Le 14/04/2015 14:05, Ben Hutchings a écrit :
On Tue, 2015-04-14 at 13:24 +0200, Francois-Regis Vuillemin wrote:
Here is the console log :
[...]
Running bootscript from mmc ...
## Executing script at 8200
Non-mainline u-boot or old-style mainline u-boot detected.
This boot script uses the unified bootcmd handling of mainline
u-boot =v2014.10, which is not available on your system.
Please boot the installer manually.
[...]
It seems that this script isn't expected to work with the version of
u-boot that's installed on your BBB. (Which is a shame, but maybe
unavoidable.) That message could probably be improved, though.
I could have misunderstood but I thought beaglebone black was loading
uboot from sd-card (or emmc), and the log shows
U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:13:27)
which seems to be the one provided with d-i ...
Yes, that is the u-boot version in Jessie. It seems like the
upstream BBB u-boot maintainer has not made the move towards
using the unified boot environment (config_distro_bootcmd.h)
which was introduced with u-boot 2014.10 and which is used by
many other platforms, so the BeagleBoneBlack still uses the old
platform-specific default environment in u-boot 2014.10. The
boot script used by the installer depends on the new unified boot
environment, which is why you get the error message quoted above.
Vagrant, could you perhaps take a look at the issue?
Did some troubleshooting (far more than I expected, now I remember why I
hadn't already done this for BBB), and came up with a patch for u-boot
that makes it work with d-i by emulating some distro bootcmd variables
(similar to the patch for wandboard), and a small patch to flash kernel
to support the change in how the bootpart variable is used.
I've tested that it boots the armhf daily hd-media installer and boots
an installed system. I could upload a new version of u-boot if it's
deemed worth it; otherwise we'll just need more complicated instructions
for manually loading the installer on d-i. FWIW, The netboot media via
tftp works without any changes.
If the user ever used u-boot's saveenv command, it may take
considerable effort resetting the environment using env default -a
followed by manually setting board_name, findfdt and/or fdtfile
variables so that it detects the correct .dtb. I didn't have consistant
success zeroing out the boot device, but in theory that should work too.
Index: u-boot/include/configs/am335x_evm.h
===
--- u-boot.orig/include/configs/am335x_evm.h
+++ u-boot/include/configs/am335x_evm.h
@@ -75,7 +75,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
boot_fdt=try\0 \
- bootpart=0:2\0 \
+ bootpart=2\0 \
bootdir=/boot\0 \
bootfile=zImage\0 \
fdtfile=undefined\0 \
@@ -85,6 +85,7 @@
name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}\0 \
optargs=\0 \
mmcdev=0\0 \
+ boot_targets=mmc0 mmc1\0 \
mmcroot=/dev/mmcblk0p2 ro\0 \
mmcrootfstype=ext4 rootwait\0 \
rootpath=/export/rootfs\0 \
@@ -115,7 +116,7 @@
loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0 \
bootscript=echo Running bootscript from mmc${mmcdev} ...; \
source ${loadaddr}\0 \
- loadbootenv=load mmc ${bootpart} ${loadaddr} ${bootenv}\0 \
+ loadbootenv=load mmc ${mmcdev}:${bootpart} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
env import -t -r $loadaddr $filesize\0 \
ramargs=setenv bootargs console=${console} \
@@ -123,12 +124,12 @@
root=${ramroot} \
rootfstype=${ramrootfstype}\0 \
loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0 \
- loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
- loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
+ loadimage=load mmc ${mmcdev}:${bootpart} ${loadaddr}
${bootdir}/${bootfile}\0 \
+ loadfdt=load mmc ${mmcdev}:${bootpart} ${fdtaddr}
${bootdir}/${fdtfile}\0 \
script=boot.scr\0 \
scriptfile=${script}\0 \
loadbootscript= \
- load mmc ${bootpart} ${loadaddr} ${scriptfile};\0 \
+ load mmc ${mmcdev}:${bootpart} ${loadaddr} ${scriptfile};\0 \
bootscript=echo Running bootscript from mmc ...; \
source ${loadaddr}\0 \
mmcloados=run mmcargs; \
@@ -146,6 +147,7 @@
bootz; \
fi;\0 \
mmcboot=mmc dev ${mmcdev}; \
+ setenv devnum ${mmcdev}; \
if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootscript; then
Bug#782574: installation-reports: d-i does not boot on beaglebone black
Hi,
Le 14/04/2015 14:05, Ben Hutchings a écrit :
On Tue, 2015-04-14 at 13:24 +0200, Francois-Regis Vuillemin wrote:
Package: installation-reports
Severity: important
Tags: d-i
Here is the console log :
[...]
Running bootscript from mmc ...
## Executing script at 8200
Non-mainline u-boot or old-style mainline u-boot detected.
This boot script uses the unified bootcmd handling of mainline
u-boot =v2014.10, which is not available on your system.
Please boot the installer manually.
[...]
It seems that this script isn't expected to work with the version of
u-boot that's installed on your BBB. (Which is a shame, but maybe
unavoidable.) That message could probably be improved, though.
I could have misunderstood but I thought beaglebone black was loading
uboot from sd-card (or emmc), and the log shows
U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:13:27)
which seems to be the one provided with d-i ...
Can you find instructions for 'boot the installer manually'? What could
we do to improve the documentation?
U-Boot# setenv devtype mmc
U-Boot# setenv devnum 0
U-Boot# setenv bootpart 1
U-Boot# load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} vmlinuz \
load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} dtbs/${fdtfile} \
load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} initrd.gz \
echo Booting the Debian installer... \
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
reading vmlinuz
3182760 bytes read in 190 ms (16 MiB/s)
reading dtbs/am335x-boneblack.dtb
29018 bytes read in 37 ms (765.6 KiB/s)
reading initrd.gz
12156022 bytes read in 704 ms (16.5 MiB/s)
Booting the Debian installer...
Kernel image @ 0x8200 [ 0x00 - 0x3090a8 ]
## Flattened Device Tree blob at 8800
Booting using the fdt blob at 0x8800
Loading Ramdisk to 8f468000, end 8c76 ... OK
Loading Device Tree to 8f45d000, end 8f467159 ... OK
Starting kernel ...
Nothing else ...
addresses seem correct :
U-Boot# printenv kernel_addr_r fdt_addr_r ramdisk_addr_r filesize
kernel_addr_r=0x8200
fdt_addr_r=0x8800
ramdisk_addr_r=0x8808
filesize=5ab
U-Boot#
Cheers,
--
François-Régis
signature.asc
Description: OpenPGP digital signature
