BeagleBoard booting to the desktop

Can someone please remind me why BeagleBoards don’t boot to the desktop? I’ve searched without success, though I’m sure I read something about it on the ROOL site.

Because SCSI isn’t the configured file system, so !Boot is not found. See this thread for a way to change that.

Because SCSI isn’t the configured file system, so !Boot is not found. See this thread for a way to change that.

Thanks, I knew I’d seen it… it throws up some further questions:

• Even if my BB had a battery connected to it (and it doesn’t), there is AFAIK no hardware equivalent to the 240 bytes of CMOS RAM. Is there a functional equivalent somewhere?

• Should the configured filing system remain over a reboot? (Clearly not if there isn’t a functional equivalent of the CMOS RAM.)

• Can I patch the BB ROM image to boot from SCSIFS? And I really do mean patch, not recompile – this is a step that I’d like to be able to point other beginners at doing.

• Didn’t I read somewhere that I may fall foul of a timeout reading the “disc”? There is still a known bug that means USB devices may not be seen for up to 20 seconds, though I don’t know whether that applies on boot-up. (It does apply to devices inserted later.)

• Shouldn’t the BB ROM image default to SCSIFS? It’s difficult to think of any other appropriate default FS.

Shouldn’t the BB ROM image default to SCSIFS? It’s difficult to think of any other appropriate default FS.

Fat32FS?

Even if my BB had a battery connected to it (and it doesn’t), there is AFAIK no hardware equivalent to the 240 bytes of CMOS RAM. Is there a functional equivalent somewhere?

Not at the moment, no. It’ll be a while until we can get CMOS RAM/NVRAM working – there’s a fair amount of code that would be needed for either approach (SD card or NAND), and various issues that could result if the HAL is trying to do low-level NVRAM access at the same time as the OS is trying to read/write from an SD/NAND filesystem.

Can I patch the BB ROM image to boot from SCSIFS? And I really do mean patch, not recompile – this is a step that I’d like to be able to point other beginners at doing.

Not really. Patching the ROM is possible, but it would be a bit tricky writing a program that can identify the patch offsets automatically (to allow it to cope with different ROM source code, compiler versions, etc.)

Didn’t I read somewhere that I may fall foul of a timeout reading the “disc”?

Yes – see this thread

Fat32FS?

Only if you build it into a ROM image :) Eventually we’ll have FS drivers for the SD card & NAND, but for the time being SCSIFS is the only FS that can really be used as the default.

This week I’m planning on doing those SCSISoftUSB tweaks I talked about in the thread I linked to above; then I’ll do the CMOS tweaks so that SCSIFS is the default FS and make sure the OS runs the boot sequence on startup.

It’ll be a while until we can get CMOS RAM/NVRAM working – there’s a fair amount of code that would be needed for either approach (SD card or NAND)...

My interpretation of this BB XM discussion is that there will be no NAND on the new XM boards.

Yes, it does look like they’ll be ditching the NAND. Luckily it won’t affect us much – I think it’s going to be a lot easier to write a CMOS/NVRAM driver that uses the SD card than to write one that uses the NAND.

If there’s no NAND, how will the board boot?

Eventually we’ll have FS drivers for the SD card

Presumably the HAL allows (or will allow) us to call code that accesses the SD card, which has to be present from reset in order for the boot script to be read?

If there’s no NAND, how will the board boot?

The OMAP has a builtin ROM containing a ‘basic’ bootloader. That bootloader is capable of looking for code in (IIRC) four locations – NAND, SD, USB (if the board is connected to a host PC via the OTG port), and serial. There’s a set of boot source selection pins which the bootloader samples to determine which order to search the various devices.

The ROM bootloader would typically go on to load a copy of TI’s x-loader, which is a slightly more capable bootloader (Although I’m not entirely sure what purpose it serves most of the time, since it’s possible to create u-boot binaries that the ROM bootloader can load directly). Then x-loader would load u-boot, u-boot would search for a boot script, and then take the appropriate action to load your OS of choice (e.g. follow the boot script or just use the settings that were saved in NAND - although saving settings in NAND obviously won’t be possible on the XM!)