Booting Archlinux from microSD (again)

GoogleGroups
1

OK I asked this question before and I was never able to resolve it.

I have an image (application) on microSD card that I want to distribute. It uses Archlinux.

I don’t want the user to have to play with boot directories pushing buttons or anything like that. I just want it to boot at power up.

As long as a distribution (stock) image is on the eMMC it will not boot the SD card unless the boot button is held down at power up.

I can get around this by wiping the eMMC but I do not want a user getting an image on SD and having to do that.

Is there anything I can do on the SD card (boot record) to cause it to boot directly from SD regardless of what is on eMMC.

Debian apparently has no problem with this. It seems to be an Archlinux issue.

If therei s an answer please pass along the code or point me to it.

2

again edit your uEnv.txt

3

Use this as a reference, it's fully compatible back to Angstrom
2013.06.20 on eMMC

https://github.com/beagleboard/image-builder/blob/master/target/boot/beagleboard.org.txt

Regards,

4

OK I asked this question before and I was never able to resolve it.

I have an image (application) on microSD card that I want to distribute. It uses Archlinux.

I don’t want the user to have to play with boot directories pushing buttons or anything like that. I just want it to boot at power up.

As long as a distribution (stock) image is on the eMMC it will not boot the SD card unless the boot button is held down at power up.

I can get around this by wiping the eMMC but I do not want a user getting an image on SD and having to do that.

Is there anything I can do on the SD card (boot record) to cause it to boot directly from SD regardless of what is on eMMC.

The only way to do this is to remove the resistor R68 and place that resistor on the R93 pads. This is the equivalent of pressing the Boot button permanently. If you don’t do that, the processor will attempt to load u-boot from the eMMC and if the SDCard is installed, it will load everything else from the SDCard. The Boot button only changes which u-boot is used.

Regards,
John

5

OK this does not work on Archlinux. Besides the fact Archlinux does not have initrd there must be some other issue holding it up. We are getting a serial connection hooked up to look at that.

The answer about the only way was to remove a resistor is NOT a good answer. First of all it is not something you would do when distributing and image to be written on an SD card to a user. Hack your board so it works! No way.

I would like to get this fixed but an easy answer would be to have a script that does a one time run of zeroing the eMMC on first boot of ArchLinux on the SD card. We have no reason to use the eMMC card in our application. I wish there was a HW switch or jumper on the BBB to disable it. That would make things much easier.

So please don’t go hacking your board, just nuke the code on the eMMC. It will then boot happily from the SD card.

Hopefully we will find a better way so we won’t have to do that. I will report back in a few days with any progress.

6

OK this does not work on Archlinux. Besides the fact Archlinux does not have initrd there must be some other issue holding it up. We are getting a serial connection hooked up to look at that.

The answer about the only way was to remove a resistor is NOT a good answer. First of all it is not something you would do when distributing and image to be written on an SD card to a user. Hack your board so it works! No way.

You asked for a solution that will work “no matter what is on the eMMC”. If you have u-boot on the eMMC, BBB will use it, period. No script or anything else for that matter will prevent this. Remove u-boot from the eMMC and BBB will use u-boot from the SDCard. With SYS_BOOT2 high (Boot not pressed), the boot sequence is MMC1 (eMMC), MMC0 (SDCard), UART0, USB0. If SYS_BOOT2 is low (Boot button pressed) the boot sequence is SPI0, MMC0, USB0, UART0.

Regards,
John

7

or why not just edit the uEnv.txt on the eMMC?

8

or why not just edit the uEnv.txt on the eMMC?

It is u-boot default environment that loads the uEnv.txt file. uEnv.txt only augments the existing scripts already present in the u-boot environment. Nothing that you do to the uEnv.txt will prevent BBB from using the u-boot on the eMMC.

Regards,
John

9

hmm strange

10

John, what ? I have “booted” from multiple types of devices, and have never had to hold down the power button. No modification, nothing. IN fact, I wrote a blog post on netbooting Debian ( TFTP / NFS rootfs ) and had a comment come back telling me this method worked for ARCH, and busybox as well.

Looking at the link Robert gave, those setting in a uEnv.txt file should work. It probably would not hurt of the OP built his / her own uboot / MLO too . . .

11

Does "reference" mean something else where you are from?

So take out the "initrd"

from:
loadfiles=run loadkernel; run loadinitrd; run loadfdt
uenvcmd=run loadfiles; run mmcargs; bootz ${loadaddr}
${initrd_addr}:${initrd_size} ${fdtaddr}

to:

loadfiles=run loadkernel; run loadfdt
uenvcmd=run loadfiles; run mmcargs; bootz ${loadaddr} - ${fdtaddr}

easy peasy...

Regards,

12

Confusion galore…

When the board is powered on it boots from mmc1 (eMMC) as per SRM. It loads the uBoot files (including uEnv.txt) form eMMC.

when mmc1 does not hold a valid uBoot, or when the boot button is held down it boots from mmc0 (SD-card)

Most uBoot implementations work in reverse. When a valid /boot/zImage is availale on the SD-card it will default to booting Linux from SD, if not it will boot Linux from eMMC.

when a reboot is issued, the board boots as previously selected. (no need to press the boot button). When the board is shutdown it resets to default (mmc1)

It is pretty well documented in the SRM, but that is only valid for the uBoot phase

I makes a difference when you talk about uBoot booting or Linux booting.

LP

13

OK a couple of answers to those who responded.

Taking out initrd did not fix the problem. We are a little bit in the dark though until we get the serial port hooked up to see what is going on.

Thanks for the explanation of the boot sequence.

It is becoming clear that there may not be a fix that does not involve changing something in the eMMC. If I finally determine that is the case then I think the option I will take is to include in my image a one time first boot script that zero’s the first 1M of the eMMC. I know most that would read this are much more savvy then the users I would send this image to. I cannot expect a user to start mucking around with editing the eMMC. Hopefully there will be a better way.

Why the current Debian will boot to MicroSD with the stock eMMC and Archlinux will not is the question. I am assuming it has to have something to do with the boot partition of Archlinux vs. Debian on the SD card since the eMMC is the same.

My Archlinux stock boot looks like this -

MLO u-boot.img uEnv.txt

[root@BBBdoug sbin]# cat /mnt/uEnv.txt
uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt; run mmcboot; fi;
findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv mmc1 0; fi
findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv mmc0 1; else setenv mmc0 0; fi
mmcroot=/dev/mmcblk0p2 rw
loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
optargs=coherent_pool=1M

As you can see the Archlinux kernel is located in the root partition and referenced in uEnv.txt

14

So just wait till you get your serial cable. Everything till then is
just a blind guess.

The reason "Debian" works, is because I set it up to "work" with
default bootloader.

Regards,

15

Robert, yes, that is my conclusion and I will report back after we get more information. Thanks.

16

Last time I bothered to look at the uboot source code I am fairly sure uSD was the first in the roundrobin.

Regardless, I have a board booted now that has Angstrom on the eMMC still, and uboot MLO, plus the kernel on uSD, with the rootfs on an NFS server. Freshly built a week or two ago.

$ uname -a
Linux arm 3.8.13-bone47 #1 SMP Mon Apr 14 04:38:52 MST 2014 armv7l GNU/Linux
$ df -h /
Filesystem Size Used Avail Use% Mounted on
192.168.0.1:/home/william/rootfs 49G 4.9G 41G 11% /
$ nano /boot/uboot/uEnv.txt

kernel_file=zImage
initrd_file=uInitrd

serverip=192.168.0.1
ipaddr=192.168.0.2
static_ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:arm
rootpath=/home/william/rootfs,rsize=16384,wsize=16384
console=ttyO0,115200n8
optargs=ipv6.disable=1

#mmcroot=/dev/mmcblk0p2 ro
#mmcrootfstype=ext4 rootwait fixrtc

loadkernel=load mmc ${mmcdev}:${mmcpart} 0x80200000 ${kernel_file}
loadinitrd=load mmc ${mmcdev}:${mmcpart} 0x81000000 ${initrd_file}; setenv initrd_size ${filesize}
loadfdt=load mmc ${mmcdev}:${mmcpart} 0x815f0000 /dtbs/${fdtfile}

#mmcargs=setenv bootargs console=${console} root=${mmcroot} rootfstype=${mmcrootfstype}
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},vers=3 rw iip=${static_ip}

#just zImage
boot_ftd=run loadkernel; run loadfdt
uenvcmd=run boot_ftd; run netargs; bootz 0x80200000 - 0x815f0000

#zImage + uInitrd: where uInitrd has to be generated on the running system.
#boot_ftd=run loadkernel; run loadinitrd; run loadfdt
#uenvcmd=run boot_ftd; run mmcargs; bootz 0x80200000 0x81000000:${initrd_size} 0x815f0000

NOTE: The above uEnv.txt file is /was provided by none other than Robert C Nelson answering the OP’s post here. Slightly modified by myself of course. THis causes the BBB to “boot” from the uSD card, then mount the rootfs over our network provided by a Debian NFS server. Allso, YES optargs=ipv6.disable=1 does work . .

Anyway, yes you’re only spinning your wheels until you get a FTDI cable / module hooked up. OR If you have a MSP430 Launchpad v1.5, and are in a hurry, I could link you to a post I made about using the Launchpad instead. However this may not work depending on how far into the boot process you’re getting. As uboot is hardcoded to use 115200 bps when it first starts up. The launchpad is only capable of 9600 bps.

17

Confusion galore…

When the board is powered on it boots from mmc1 (eMMC) as per SRM. It loads the uBoot files (including uEnv.txt) form eMMC.

I don’t think this is correct. Looking at the default u-boot env, if an SDCard is installed, it will load the uEnv.txt from the SDCard.

Regards,
John

18

John, what ? I have “booted” from multiple types of devices, and have never had to hold down the power button. No modification, nothing. IN fact, I wrote a blog post on netbooting Debian ( TFTP / NFS rootfs ) and had a comment come back telling me this method worked for ARCH, and busybox as well.

You shouldn’t have to press the Boot button. If the eMMC has a valid u-boot, BBB will use the eMMC u-boot. If the eMMC does not have a valid u-boot, BBB will use the SDCard u-boot. The purpose of the Boot button is to prevent the BBB from using the eMMC u-boot.

Regards,
John

19

John, what you just said does not jibe with your last post about uSD being first in the roundrobin, and is also incorrect.

I have Angstrom from last year still installed on the eMMC of my board, which ONLY boots when i remove the “boot” uSD that is in it now. Otherwise it boots from the uSD.

Am I misunderstanding what you’re saying ? It could also be that we’re talking about two different uboots. The one I am using is patched by a patch provided by RCN on his cross compile Debian instructions. Perhaps you’re speaking of “stock” ?

http://eewiki.net/display/linuxonarm/BeagleBone+Black

20

Last time I bothered to look at the uboot source code I am fairly sure uSD was the first in the roundrobin.

Look at the BBB schematics. On page 6, there is a table and it shows the boot sequence.

Regards,
John