John, I do not care about the schematics. I have been booting this board from uSD, netboot, and USB, since last year All the while the original Angstrom with the kernel upgraded to 3.8.11 is on the eMMC and perfectly functional.
So, you’re telling me it seems from “book” information, and I am telling you what is possible via practical hands on.
Anyway, I am starting to feel like I am talking to a brick wall, so lets stop hijacking the OP’s post. My fault.
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” ?
The boot sequence has nothing to do with u-boot. The BBB bootrom uses the state of SYS_BOOT pins at POR to decide the boot sequence. See Section 26.1.5 in the TRM. Also, look at Table 26.7 in the TRM.
Regards,
John
John, I do not care about the schematics. I have been booting this board from uSD, netboot, and USB, since last year All the while the original Angstrom with the kernel upgraded to 3.8.11 is on the eMMC and perfectly functional.
So, you’re telling me it seems from “book” information, and I am telling you what is possible via practical hands on.
Anyway, I am starting to feel like I am talking to a brick wall, so lets stop hijacking the OP’s post. My fault.
I didn’t mean to upset you and I apologize for that. Here is a non book, hands on test that may help. Change the version of your u-boot on your SDCard and then reboot and see which version of u-boot is displayed on the debug console. I’m hoping that the u-boot version in the boot console will not change or I’ve got this completely wrong.
Regards,
John
I didn’t mean to upset you and I apologize for that. Here is a non book,
hands on test that may help. Change the version of your u-boot on your
SDCard and then reboot and see which version of u-boot is displayed on the
debug console. I’m hoping that the u-boot version in the boot console will
not change or I’ve got this completely wrong.
As long as the bootrom finds a valid header in the MLO file, it'll
boot from that device. (the mmc interface wired to the eMMC has
priority over mmc interface wired to the microSD in the bootroom
order).
Regards,
I should also note, one confusing thing about this. On the "orignial"
beagle, we got into situations where MLO was loaded off NAND and the
final u-boot.img was loaded from microSD. So MLO would print out
weither it's booting u-boot.img from NAND/mmc.
On the bbb, i haven't seen this case happen yet. (load MLO from eMMC,
then load u-boot.img from microSD)
Regards,
I didn¹t mean to upset you and I apologize for that. Here is a non book,
hands on test that may help. Change the version of your u-boot on your
SDCard and then reboot and see which version of u-boot is displayed on
the
debug console. I¹m hoping that the u-boot version in the boot console
will
not change or I¹ve got this completely wrong.As long as the bootrom finds a valid header in the MLO file, it'll
boot from that device. (the mmc interface wired to the eMMC has
priority over mmc interface wired to the microSD in the bootroom
order).
Hi Robert,
Thanks for clearing this up. I was beginning to doubt myself. So to be
clear, we need to remove the MLO from the eMMC to make the BBB boot from
the SDCard? What happens if there is a valid MLO on the eMMC and there is
no u-boot on the eMMC?
Regards,
John
I didn¹t mean to upset you and I apologize for that. Here is a non book,
hands on test that may help. Change the version of your u-boot on your
SDCard and then reboot and see which version of u-boot is displayed on
the
debug console. I¹m hoping that the u-boot version in the boot console
will
not change or I¹ve got this completely wrong.As long as the bootrom finds a valid header in the MLO file, it’ll
boot from that device. (the mmc interface wired to the eMMC has
priority over mmc interface wired to the microSD in the bootroom
order).
Hi Robert,Thanks for clearing this up. I was beginning to doubt myself. So to be
clear, we need to remove the MLO from the eMMC to make the BBB boot from
the SDCard?
That’s one way, a good uEnv.txt is just easier.
What happens if there is a valid MLO on the eMMC and there is
no u-boot on the eMMC?
It should halt saying can’t find uboot.img
I didn¹t mean to upset you and I apologize for that. Here is a non book,
hands on test that may help. Change the version of your u-boot on your
SDCard and then reboot and see which version of u-boot is displayed on
the
debug console. I¹m hoping that the u-boot version in the boot console
will
not change or I¹ve got this completely wrong.As long as the bootrom finds a valid header in the MLO file, it’ll
boot from that device. (the mmc interface wired to the eMMC has
priority over mmc interface wired to the microSD in the bootroom
order).
Hi Robert,Thanks for clearing this up. I was beginning to doubt myself. So to be
clear, we need to remove the MLO from the eMMC to make the BBB boot from
the SDCard?That’s one way, a good uEnv.txt is just easier.
Exactly, and now I cannot even remember why we went down this road 
Thanks for all your help.
Regards,
John
upset me ? no you did not, but what Robert just said verifies what I’ve been saying all along. All you need is a good uEnv.txt.
I am not an EE by ant stretch of the imagination, but I know I’ve been “booting” from uSD since at least June last year. So, when i say “I dont care about the schematics” I mean that MAYBE the hardware may be wired that way, but software can and will override( or at least seems this way ).
End result, no having to pull x.y.z pin low, or whatever. You just use a config line in uEnv.txt.
John yeah I can not test that. All I have for a tty into uboot is an MSP430 v1.5 Launchpad, with the MCU pulled to serve as a cheap way to get a console AFTER uEnv.txt has loaded. This has to do with the fact that the Launchpad is 9600 bps only, and from what I can tell uboot is hardwired at 115200 bps until uEnv.txt is read and applied.
What I mean all along when I say “boot/booting” is that I pull the kernel from x.y.z location. Which is to say I know that comes from the uSD. As for MLO / uboot ? I really do not know, what would happen if i completely erased the eMMC ?
upset me ? no you did not, but what Robert just said verifies what I’ve been saying all along. All you need is a good uEnv.txt.
I am not an EE by ant stretch of the imagination, but I know I’ve been “booting” from uSD since at least June last year. So, when i say “I dont care about the schematics” I mean that MAYBE the hardware may be wired that way, but software can and will override( or at least seems this way ).
End result, no having to pull x.y.z pin low, or whatever. You just use a config line in uEnv.txt.
In the end, I think it all comes down to semantics. You are correct in that you can boot from your SDCard without pressing the boot button and I’m not disputing that. What is happening is that the bootrom is loading the eMMC MLO, which loads the eMMC u-boot, which loads the SDCard uEnv.txt, which modifies the u-boot env and then boots from the SDCard. No need to press any boot button. Now if the MLO or u-boot on the eMMC does not work, it will be necessary to use the u-boot on the SDCard and that is the purpose of the boot button. Thus is is not possible to brick the BBB.
Anyway, as I said the Robert, I cannot even remember why we went down this road.
Regards,
John
John yeah I can not test that. All I have for a tty into uboot is an MSP430 v1.5 Launchpad, with the MCU pulled to serve as a cheap way to get a console AFTER uEnv.txt has loaded. This has to do with the fact that the Launchpad is 9600 bps only, and from what I can tell uboot is hardwired at 115200 bps until uEnv.txt is read and applied.
What I mean all along when I say “boot/booting” is that I pull the kernel from x.y.z location. Which is to say I know that comes from the uSD. As for MLO / uboot ? I really do not know, what would happen if i completely erased the eMMC ?
Well, as Robert said, if the eMMC does not contain a MLO with a valid header, the BBB will look for an MLO on the next device in the boot sequence, which in this case is the SDCard.
Regards,
John
I cannot even remember why we went down this road.
Me either. except that the OP was concerned about making hardware modifications to his/her board, and by extension having others do the same. Something about ARCH Linux not working in this context, when I know that it does.
All i really wanted to stress is that reconfiguring the BBB hardware should not have to be done.
OK me again - the original poster. No new info but I wanted to comment on the later posts.
First of all if there is nothing on the eMMC it boots fine from the uSD. On one of my BBB’s I zero’ed the eMMC and it just boots from the uSD. No buttons just boots.
Just to make it clear. I want to be able to boot at power up from the uSD running Archlinux without pushing modifying or changing anything on the stock BBB or its eMMC. If this can be achieved with changes to the uSD cards boot partition that would be great. Someone keeps saying it is working - well tell me what files you have on the Archlinux boot partition. Show me the dates? Also the contents of the uEnv.txt file on the uSD.
The concern I have is thatin the future if changes are made on the eMMC boot record as shipped it might screw up the boot of the uSD. Perhaps the best way to do this is just to zap the eMMC. No one is going to need the Angstrom code anyway and if they ever do they can recreate.
Doug, unless you feel like telling us in exact steps exactly the steps you’ve made in detail, your best bet is to wait for your FTDI serial cable / module. After that if the output is not obvious enough for you to fix your issue perhaps you can paste the output of the uboot console. Output put on pastebin preferably( easier to read, at least for me ).
William,
I only made that statement because you were the one that emphatically said it does work with Archlinux. If you know that for a fact then you should have the boot code that works. It would not be any different for me.
OK me again - the original poster. No new info but I wanted to comment on the later posts.
First of all if there is nothing on the eMMC it boots fine from the uSD. On one of my BBB’s I zero’ed the eMMC and it just boots from the uSD. No buttons just boots.
Just to make it clear. I want to be able to boot at power up from the uSD running Archlinux without pushing modifying or changing anything on the stock BBB or its eMMC. If this can be achieved with changes to the uSD cards boot partition that would be great. Someone keeps saying it is working - well tell me what files you have on the Archlinux boot partition. Show me the dates? Also the contents of the uEnv.txt file on the uSD.
Archlinux is just a filesystem. You are still using the same kernel as all the other distributions. The only thing that might be different is whether your distribution requires initrd. Robert suggested that you make the following changes to your uEnv.txt:
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}
If this doesn’t work, then I suggest you run each u-boot command manually and use echo to print out the contents of each variable after it is set. In the u-boot console, start with the commands on the line that starts with “bootcmd”. Each command is separated by a “;”.
Regards,
John
I cannot even remember why we went down this road.
Me either. except that the OP was concerned about making hardware modifications to his/her board, and by extension having others do the same. Something about ARCH Linux not working in this context, when I know that it does.
All i really wanted to stress is that reconfiguring the BBB hardware should not have to be done.
You are correct. I think I was answering OP’s question regarding "booting from the SDCard no matter what is on the eMMC”. Perhaps that is why I went down this rat hole. Sorry about that.
Regards,
John
And i this helps as it helped me understand part of the process . . .
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l57
The concern I have is thatin the future if changes are made on the eMMC boot
record as shipped it might screw up the boot of the uSD. Perhaps the best
way to do this is just to zap the eMMC. No one is going to need the Angstrom
code anyway and if they ever do they can recreate.
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.
By default it expects these 2 files and a dtbs directory in the fat partition
/zImage
/initrd.img
/dtbs/*.dtb
So if you make sure your ARCH distro has those 2 (or 3 files) saved to
the fat partition. Your uEnv.txt is as simple as:
uenvcmd=run loadimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}
If you want to load /zImage * /dtbs/*black*.dtb and boot...
You can see the u-boot patch here:
https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
It also solves the "i inserted a blank/formated/etc microSD and now
the board won't boot" problem..
Regards,