Oh those days are coming! Trust me, you’ll enjoy the way i setup the bootloader flashed to the eMMC in the new default debian based image. It’ll make things for Arch and other distro’s much easier to control boot, without messing with the eMMC.
It will “only” try to bootup from the microSD if it contains a small fat partition with a “uEnv.txt” file with the variable “uenvcmd” defined. Otherwise it always boots off eMMC.
Hmm sounds interesting, and pretty cool, nut can help but wonder if that means good or bad news for me.
It also solves the "i inserted a blank/formated/etc microSD and now the board won’t boot" problem…
Oh those days are coming! Trust me, you’ll enjoy the way i setup the
bootloader flashed to the eMMC in the new default debian based image.
It’ll make things for Arch and other distro’s much easier to control
boot, without messing with the eMMC.
It will “only” try to bootup from the microSD if it contains a small
fat partition with a “uEnv.txt” file with the variable “uenvcmd”
defined. Otherwise it always boots off eMMC.
Hmm sounds interesting, and pretty cool, nut can help but wonder if that means good or bad news for me.
No change for you, as your uEnv.txt is based on my default one and it meets the requirements.
Oh those days are coming! Trust me, you’ll enjoy the way i setup the
bootloader flashed to the eMMC in the new default debian based image.
It’ll make things for Arch and other distro’s much easier to control
boot, without messing with the eMMC.
Robert,
I am not sure what you are saying here. In one sentence you are saying something about flashing a bootloader to the eMMC and then in the last sentence saying not messing with the eMMC. Does the Debian uSD install change something on the eMMC?
I am trying to come up with the best approach in distributing an Archlinux image on uSD. that will boot without user intervention. We know that zeroing the first 1M of blk1 will permanently fix it. Another less harmful and reversible method is to mount blk1p1 and rename MLO to MLO.keep or anything other than just MLO. You can rename it back and have it boot from eMMC if you desire.
I don’t like the idea of configuring this to work (if we can) using the current blk1p1 (eMMC boot) because that could change in the future. Our application does not care about the eMMC at all. I wish there was no eMMC even there. It would be great if they could make a version without it at a cheaper or same price rather than the increase we are going to see with rev C. It would have been as simple as putting a jumper on the board to set the default boot.
I think the approach we will tak is the renaming of the eMMC MLO file. A couple of scripts distributed with our image would either turn it off or on so the user would have the option one way or the other.
Oh those days are coming! Trust me, you'll enjoy the way i setup the
bootloader flashed to the eMMC in the new default debian based image.
It'll make things for Arch and other distro's much easier to control
boot, without messing with the eMMC.
Robert,
I am not sure what you are saying here. In one sentence you are saying
something about flashing a bootloader to the eMMC and then in the last
sentence saying not messing with the eMMC. Does the Debian uSD install
change something on the eMMC?
This is in reference to CircuitCo changing over the production boards
from Angstrom to my Debian image. Which is occurring right now. So
newer boards will have an update u-boot in eMMC that is a little more
user friendly then the older Angstrom image.
I am trying to come up with the best approach in distributing an Archlinux
image on uSD. that will boot without user intervention. We know that zeroing
the first 1M of blk1 will permanently fix it. Another less harmful and
reversible method is to mount blk1p1 and rename MLO to MLO.keep or
anything other than just MLO. You can rename it back and have it boot from
eMMC if you desire.
I don't like the idea of configuring this to work (if we can) using the
current blk1p1 (eMMC boot) because that could change in the future. Our
application does not care about the eMMC at all. I wish there was no eMMC
even there. It would be great if they could make a version without it at a
cheaper or same price rather than the increase we are going to see with rev
C. It would have been as simple as putting a jumper on the board to set the
default boot.
I think the approach we will tak is the renaming of the eMMC MLO file. A
couple of scripts distributed with our image would either turn it off or on
so the user would have the option one way or the other.
YUK!!! I'm very disappointed, it is not a solution to "touch" the
eMMC just to make your microSD image work. You have the knowledge to
build a Archlinux image from scratch yet you can't debug
u-boot/uEnv.txt over a serial connection?
1: u-boot source + patch is available
2: u-boot binary: tells you it's "boot script order" : type "printenv"
3: "uEnv.txt" is documented in so many places
I don’t think you get my point or maybe I am not understanding the BBB evolution. We have a large number of individuals who have already purchased rev B boards. They will not have any updated eMMC code. What is there is there. On the other hand some will be purchasing the Rev C which will be available in a few weeks.
If there is a fix we can do in Arch Linux that will universally fix our boot issue for any circumstance of eMMC state, Rev B, C without touching eMMC then I am all for it. If not then getting eMMC out of the way is the best choice.
BTW we would be using Debian but it clearly does not work for our application. Besides periodic crashes we had problems with USB audio. Runnng Archlinux solved all those problems.
I don’t think you get my point or maybe I am not understanding the BBB evolution. We have a large number of individuals who have already purchased rev B boards. They will not have any updated eMMC code. What is there is there. On the other hand some will be purchasing the Rev C which will be available in a few weeks.
If there is a fix we can do in Arch Linux that will universally fix our boot issue for any circumstance of eMMC state, Rev B, C without touching eMMC then I am all for it. If not then getting eMMC out of the way is the best choice.
Once you get a serial adapter on the board, shoot us a printenv pastebin
BTW we would be using Debian but it clearly does not work for our application. Besides periodic crashes we had problems with USB audio. Runnng Archlinux solved all those problems.
Laughs not a problem, Arch is using my kernel patchset anyways that I use as beta for Ubuntu and debian, just with a custom config
