USB HDD for Beagleboard XM

I have a USB HDD for the Beagleboard XM. I need to partition it with a RISC OS partition (say 16Gbytes) and an ‘ordinary’ partition so that the RISC OS partition will be recognised with the !Boot image for the Beagleboard and the rest of the drive will be available to the Linux GUI on the Beagleboard.

I tried partitioning it FAT32 (16Gbytes) plus NTFS (133Gbytes) under Windows but plugging the drive into my Iyonix the primary partition was not recognised – hence I could not ‘ADFS’ format it using !SCSIForm.

Any ideas please?

The main purpose is to avoid the need for the current 16Gbyte Intenso pen drive that contains the !Boot image (and works OK) and avoid the use of the SD card as the primary storage for the Linus GUI (on the basis that writing to an SD card frequently shortens its life).

I seem to have asked the wrong question. The answer was to plug the HDD into the OTG port on the Beagleboard and run !SCSIForm to format it. I then copied the !Boot image from the Intenso 16Gbyte pendrive onto the newly formatted 156Gbyte USB HDD - which is recognised as SCSI::4.$ and called HardDisc4. However if I remove the pen drive (which is seen as SCSI::0.$) RISC OS does not know that the SCSI !Boot image is on mount 4 and so (without a visible desktop) I can proceed no further.

Will there be a way to tell RISC OS that the bootable drive is mount 4 (OTG port) rather than mount 0 (USB)?

You can get it to boot manually. Just type the following at the supervisor prompt.

dir SCSI::HardDisc4.$

!Boot

Clearly manual intervention will work, but that wasn’t the point. I was thinking of something like ’*Configure SCSIMount 4’ but without CMOS RAM. One option would be to set RISC OS to try SCSI::0.$ and SCSI::4.$ (and perhaps others) if not configured to do something specific?

I need to partition it with a RISC OS partition (say 16Gbytes) and an ‘ordinary’ partition so that the RISC OS partition will be recognised with the !Boot image for the Beagleboard and the rest of the drive will be available to the Linux GUI on the Beagleboard.

You won’t have much luck with that – the ADFS partition will trample all over the partition table, preventing Linux (or most other OS’s) from detecting the other partitions.

One option would be to set RISC OS to try SCSI::0.$ and SCSI::4.$ (and perhaps others) if not configured to do something specific?

We probably do need to make some changes to how RISC OS decides what device to boot from. If you’ve got multiple devices connected then you can’t be 100% sure which order they’ll be enumerated in, and you can’t even be 100% sure that they’ll have all been enumated by the time RISC OS attempts to boot. So a smarter algorithm which looks for a particular disc name may be more appropriate. Of course, this is assuming that people stick with USB booting once we have a SD/MMC driver and partition table support.

Anyway, as a temporary solution I think I’ll look into implementing the solution you suggested (check ::0 then ::4). It shouldn’t be too hard to limit this behaviour to just the OMAP3 port, keeping the Iyonix/IOMD ports intact.

Just lost my post so I’ll try again.

One possibility, to address the lack of CMOS RAM, whilst you are developing the SD/MMC driver and/or a ‘multi-booting’ approach to finding the boot device is to have (yet) another entry point that would imply ‘boot from SCSI::4.$ rather than SCSI::0.$’.

OR

Identify the place within the ROM image where drive 0 is selected as the boot device and thus allow a ‘memory’ command after the ‘fatload’ command to (for example) replace a ‘LD R2,#0’ instruction with a ‘LD R2,#4’ instruction. There is only a small number of such crucial ‘CMOS RAM’ settings – monitor and screen resolution are stored within the !Boot structure and many others can be addressed early in the !Boot sequence.

I assume you are currently following a fundamentalist approach of a single ROM image irrespective of the hardware platform and keeping the complexity in the HAL (choosing between Beagleboard and Beagleboard XM for example).

See here as to changing the default drive on boot.

This does mean you need to be able to compile your own ROM.

I think the ROM image for XM already defaults to SCSI, but drive 0.

All I am after is the location of the byte in the ROM image that would change if the default was SCSI but drive 4. The a simple patch can be applied to the ROM image itself to force drive 4. All a hack I know but only a temporary measure. I am not able to compile my own ROM just hoping someone else can compile the 14.09.2010 ROM with drive 4 as the default and note the location of the changed byte.

I’ve uploaded a XM compatible ROM here which defaults to drive 4. It also has a change to allow a 256MiB ram disc.

Many thanks.

I’ll have a look to see which byte has changed for the change in the drive number.

That’s great – I can now boot straight to the desktop with networking enabled via a Lindy adaptor. Just got to find a way to improve the screen resolution…

!Boot.Choices.Boot.PreDesk.Configure.Monitor

# 800x600@60Hz reduced blanking VESA CVT 0.48M3-R
startmode
mode_name:800 x 600
x_res:800
y_res:600
pixel_rate:35500
h_timings:32,80,0,800,0,48
v_timings:4,11,0,600,0,3
sync_pol:3
endmode

# 1024x768@60Hz reduced blanking VESA CVT 0.79M3-R
startmode
mode_name:1024 x 768
x_res:1024
y_res:768
pixel_rate:56000
h_timings:32,80,0,1024,0,48
v_timings:4,15,0,768,0,3
sync_pol:3
endmode

# 1280x720@60Hz reduced blanking VESA CVT 0.79M3-R
startmode
mode_name:1280 x 720
x_res:1280
y_res:720
pixel_rate:64000
h_timings:32,80,0,1280,0,48
v_timings:5,13,0,720,0,3
sync_pol:3
endmode

WimpMode X1280 Y1024 C256

I’ve done that already, but the best resolution I can get is 1024×768. The 1280×1024 mode seems to be too large for the monitor and auto-adjust doesn’t work for this mode. The monitor is a Samsung 206BW capable of 1680×1050 and would be great to get a bit closer to that (the 1600×1000 mode in the sample MDF won’t sync at all).

Chris, I don’t know what you’ve done to the ROM image but you haven’t just changed the drive parameters – doing an ‘fc’ on the two binary images 14.09.10 and 22.09.10 lots and lots of bytes have changed!! The whole idea was to make just a simple change (drive 4 rather than drive 0) and thus identify the location that needs to be changed in what would otherwise be a standard ROM image. Having lots of different ROM images around does not appear to be the plan.

...doing an ‘fc’ on the two binary images 14.09.10 and 22.09.10 lots and lots of bytes have changed!!

...It also has a change to allow a 256MiB ram disc.

...It also has a change to allow a 256MiB ram disc.

And it was probably made with a different C compiler version, and it probably included some of the other changes that have been checked into CVS over the past few days. And the embedded checksum & build date would be different.

And since the default CMOS RAM settings are defined by a table of (address, value) pairs, the act of adding the ‘default SCSI drive’ entry would have likely had a significant effect on the layout of the ROM image anyway (although the shuffling of all the data could obviously be avoided if a ‘default SCSI drive’ entry containing the default of 0 was added).

But even if you did get the location of the ‘default SCSI drive’ byte for one ROM image, there’s no guarantee that location won’t change when you switch to a new ROM image. So it’s probably much better to wait a few days until I add the code to allow the ROM to use some CMOS settings that have been loaded into RAM by u-boot.

I had assumed there was already a SCSI drive entry containing zero as the default, that was simply changed to 4. I’ll wait a few days for the proper (temporary!?) solution. Thanks for all your work.