• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: uBoot and booting from SD/USB?  (Read 5653 times)
cobaia
Newbie
*

Karma: 0
Posts: 14


View Profile
« on: July 14, 2009, 02:08:27 AM »

Newbie wishlist continues:

Has anyone got a system up that reliably boots from SD, having the whole FS on the SD only? Or USB?

Does uBoot support automatic recognition of bootable images on SD & USB prior to resorting to internal flash?

What steps are necessary to get a bootable format on SD or USB that works with Plug?

I've created numerous setups that boot and run from USB or CompactFlash on x86 machines and Slug, but looks like the boot setup on Plug is quite different.

Being able to have everything on removable media makes many maintenance issues much easier, as the memory can be plugged into other Linux machines, and any mistakes made can be fixed offline.

Again, I just started tinkering with this, so if this obvious, just give me a link and I go away...
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #1 on: July 14, 2009, 02:19:51 PM »

Has anyone got a system up that reliably boots from SD, having the whole FS on the SD only? Or USB?
Yes.  People have had some success at both.  An SDcard can be used for the root filesystem (in lieu of the NAND FS) w/o too much trouble, but a newer Uboot than what was supplied with the Plug is required to boot the kernel off the SDcard.  See:

http://plugcomputer.org/plugforum/index.php?topic=183.0

Also, for EXT2/3 FSs to support booting a kernel, they must have been created using the "-I 128" option (128 byte I-nodes) per:

http://plugcomputer.org/plugforum/index.php?topic=460.msg2861#msg2861

You might also want to take a look at (especially section 8; and BTW, I have no idea why rc3 loads the kernel at 0x400000 rather than the normal 0x800000):

http://plugcomputer.org/plugforum/index.php?topic=377.msg2548#msg2548

I am still booting the kernel off NAND, but using an SDcard as the root FS.  I haven't looked too seriously at booting off the SDcard, since I didn't create my FS with 128 byte I-nodes, but I agree it would be nice to be able to do so.  Let us know if you are successful.  Oh, and BTW, the SDcard goes into the slot on the Plug contact-side up.  This tripped me (and a couple other folks) up at first.

Quote
Does uBoot support automatic recognition of bootable images on SD & USB prior to resorting to internal flash?
No, but someone came up with a neat trick which essentially accomplishes the same thing:

http://www.openplug.org/plugwiki/index.php/Multi-Boot

Also, the Marvell team has proposed a new version of Uboot that is capable of checking for and automatically reflashing a new Unix if it finds suitable Unix install software on an attached thumb drive.  See:

http://plugcomputer.org/plugforum/index.php?topic=120.0

Quote
What steps are necessary to get a bootable format on SD or USB that works with Plug?
See above for the SDcard boot solution.  For USB devices, it is more problematic.  Someone correct me if I am wrong, but I've only heard of people successfully booting from a USB device when it was the only device attached to the USB port (or to some hubs when they are in turn attached to the Plug's USB port).  In the latter case, it is possible to plug in additional USB devices after the boot - until the next boot - and of course this is not a problem if the only USB device you intend to use on the Plug is your external disk.  I think some hubs might be better supported by Uboot than others.  I've never had any success with USB boots with my Plug except when I removed the hub and had a thumb drive plugged directly into the Plug.  However, here is a good description of how to go about booting from a USB device if you want to pursue it:

http://computingplugs.com/index.php/Booting_entirely_off_an_external_USB_device

Also, see:

http://plugcomputer.org/plugforum/index.php?topic=131.0

Quote
Being able to have everything on removable media makes many maintenance issues much easier, as the memory can be plugged into other Linux machines, and any mistakes made can be fixed offline.
Granted!

Quote
Again, I just started tinkering with this, so if this obvious, just give me a link and I go away...
Let us know how your attempts turn out, especially if you are successful!
« Last Edit: July 14, 2009, 02:28:16 PM by restamp » Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #2 on: September 05, 2009, 01:17:40 PM »

restamp,
I think this is one of the problems to overcome you may have hinted at earlier.  I've been running this way w the rootfs on usb for some time (booting the the rootfs from usb, kernel still in nand) after my Alpha-6 upgrade.

I am going to copy over my uImage to my currently running usb (hardrive) rootfs  as /uImage.    But I fail at the uImage mount step:

Code:
# ls -l /dev/mtd*
crw-rw---- 1 root root 90, 0 Sep  3 17:01 /dev/mtd0
crw-rw---- 1 root root 90, 1 Sep  3 17:01 /dev/mtd0ro
crw-rw---- 1 root root 90, 2 Sep  3 17:01 /dev/mtd1
crw-rw---- 1 root root 90, 3 Sep  3 17:01 /dev/mtd1ro
brw-rw---- 1 root disk 31, 0 Sep  3 17:00 /dev/mtdblock0
brw-rw---- 1 root disk 31, 1 Sep  3 17:00 /dev/mtdblock1

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "uImage"
mtd1: 1fb00000 00020000 "rootfs"

# mount -t ubifs /dev/mtdblock0 /mnt/mtdblock0/
mount: wrong fs type, bad option, bad superblock on /dev/mtdblock0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

I cant find/remember the intermediate step needed before the mount, which I think you already  know about.  Help, please.
Logged

Cordially, CqCn

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #3 on: September 05, 2009, 01:46:27 PM »

/dev/mtdblock0 is not a file system, CqCn; it is a raw partition that contains the bootable image.  You might be able to "dd if=/dev/mtdblock0 of=/uImage" and get away with it, but my guess is that it wouldn't work, especially if you have any bad blocks in that area of your NAND.  Just locate the kernel uImage on the medium you used to populate it to your NAND originally and copy that to your USB device.

BTW, I don't know of anyone who has gotten a USB boot to work reliably with multiple USB devices attached to the Plug.  That's why I have avoided this and stuck with the SDcard for my boot device/root fs.
Logged

CqCn
Full Member
***

Karma: 0
Posts: 169



View Profile
« Reply #4 on: September 05, 2009, 02:46:58 PM »

restmp,

Thank you!  BTW, I only have normally one usb drive on the usb port directly connected.  And for copying over uImage, I have no problem to make an sdcard the external device if needed.

Ok I want to follow your advise to
Quote
locate the kernel uImage on the medium you used to populate it to your NAND originally
  I dont have any notes of my steps, but I recall it went without a hitch.  Where will I find this image?  BTW, there is no easy way to check the integrity of the nand area to make the dd is the way to go.  If I cannot confirm the integrity, I do not wish to take that route.  After copy when I tried to boot, would I get any indication such as bad checksum, when I try to use if it was bad?  That is sufficient confirmation for me, it it was checking ...
Logged

Cordially, CqCn

birdman
Sr. Member
****

Karma: 4
Posts: 443


View Profile WWW
« Reply #5 on: September 05, 2009, 05:41:32 PM »

/dev/mtdblock0 is not a file system, CqCn; it is a raw partition that contains the bootable image.  You might be able to "dd if=/dev/mtdblock0 of=/uImage" and get away with it, but my guess is that it wouldn't work, especially if you have any bad blocks in that area of your NAND. 
Just out of curiosity then, how does the boot process manage to read the image correctly? Isn't it using the same principle?
Logged

Pages: [1]
Print
Jump to: