From: William Hermans <[email protected]> Reply-To: <[email protected]> Date: Monday, April 28, 2014 at 9:22 AM To: <[email protected]> Subject: Re: [beagleboard] Re: Booting Archlinux from microSD (again)
> 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 > > > > On Mon, Apr 28, 2014 at 9:16 AM, John Syn <[email protected]> wrote: >> >> From: William Hermans <[email protected]> >> Reply-To: <[email protected]> >> Date: Monday, April 28, 2014 at 8:58 AM >> >> To: <[email protected]> >> Subject: Re: [beagleboard] Re: Booting Archlinux from microSD (again) >> >>> 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 >>> >>> >>> 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. >>> >>> >>> On Mon, Apr 28, 2014 at 7:38 AM, Doug <[email protected]> wrote: >>>> Robert, yes, that is my conclusion and I will report back after we get more >>>> information. Thanks. >>>> >>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google Groups >>>> "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
