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 82000000
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

[...]
[...]

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.

Hi,

Le 14/04/2015 14:05, Ben Hutchings a écrit :

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 ...

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 \
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 @ 0x82000000 [ 0x000000 - 0x3090a8 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Ramdisk to 8f468000, end 8ffffc76 ... 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=0x82000000
fdt_addr_r=0x88000000
ramdisk_addr_r=0x88080000
filesize=5ab
U-Boot#

Cheers,

Hi,

Le 14/04/2015 15:51, François-Régis a écrit :

setenv console "ttyO0,115200n8"
setenv bootargs "${bootargs} console=${console}"

... and d-i starts on console and successfully installed jessie, uboot,
network and all !


Cheers,

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?

Regards,
Karsten

Control: tags -1 +patch
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 " \
@@ -206,13 +208,14 @@

 #define CONFIG_BOOTCOMMAND \
 	"run findfdt; " \
+	"setenv devtype mmc; " \
 	"run mmcboot;" \
-	"setenv bootpart 0:1; " \
+	"setenv bootpart 1; " \
 	"run mmcboot;" \
 	"setenv mmcdev 1; " \
-	"setenv bootpart 1:2; " \
+	"setenv bootpart 2; " \
 	"run mmcboot;" \
-	"setenv bootpart 1:1; " \
+	"setenv bootpart 1; " \
 	"run mmcboot;" \
 	"run nandboot;"



And flash-kernel will require the following patch to maintain
compatibility with the change in the use of bootpart:

diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index 1d079f8..9181ccc 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
@@ -11,7 +11,13 @@ then
 fi

 setenv device mmc
-setenv partition ${bootpart}
+if test "${devnum}" = ""
+then
+  setenv partition ${bootpart}
+else
+  setenv partition ${devnum}:${bootpart}
+fi
+
 setenv bootargs ${bootargs} @@LINUX_KERNEL_CMDLINE@@

 image_locations='/boot/ /'


live well,
  vagrant

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?

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Karsten Merker <merker@debian.org> (2015-04-15):

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.

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.

Yes, IIRC from the thread the workaround is pretty simple, certainly in
comparison with the scope of the proposed changes.

Ian.

Le 16/04/2015 09:20, Ian Campbell a écrit :

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.

...
...

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

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.

Hi Vagrant, Hi Cyril, Hi all,

Le 27/05/2015 20:36, Vagrant Cascadian a écrit :

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.

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 ?)

Le 27/05/2015 22:20, Lennart Sorensen a écrit :

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

If it's hard to install using d-i, it'll stay that way, which sounds
like a bug worth fixing to me.... :)

Good.

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

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.

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

Hi folks,

Vagrant Cascadian <vagrant@debian.org> (2015-05-27):

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.

If nobody picks the “update the docs” ball, I'll try and get that part
done.

ACK, small is good (when feasible).

Indeed, sorry again.

Mraw,
KiBi.

Hi everybody,

My 5 ¢ :

Le 03/06/2015 03:16, Vagrant Cascadian a écrit :

You will need a serial console and press a key before u-boot tries to
start d-i.