RISC OS on the TI OMAP3530 Evaluation Module?

Hi,

I’m relatively new to the RISC OS Open scene – although I’ve used earlier versions of RISC OS (3.x) eons ago, and I’m interested in seeing how things have progressed since then.

Given that ROS runs on the BeagleBoard, which contains the same SoC (albeit seemingly in a different configuration) – and that I’m one of the handful of people (un)fortunate enough to have a NABB (a TI/Mistral TMDSEVM3530) instead of a BeagleBoard, after recently being given a spare review unit that a friend had, does anyone know how feasible a port would be?

I’ve already attempted to see if I can boot a BeagleBoard ROM using U-Boot – but the seeming lack of UART output suggests that it obviously isn’t working; and from what I can understand from looking at ROS HAL and Linux kernel source code and various technical documents floating around, over the course of a few hours, there’s supposed to be a mechanism in place to prevent booting on “unsupported” hardware.

Unfortunately, my ARM Assembler knowledge is lacking, and I haven’t got any JTAG emulation hardware (or a machine running RISC OS), so I probably can’t help too much with implementation.

Any thoughts?

NABB (a TI/Mistral TMDSEVM3530)

Is it this OMAP35x EVM?

see if I can boot a BeagleBoard ROM using U-Boot

If you think it’s mainly a video issue, going back to your previous RO3.x days, you’ll probably remember that Ctrl-G at the command line should give you a beep. Maybe you’ve already tried this. It may also be worth blind typing Desktop, then calling the shutdown by Ctrl-Shift-F12 followed by Enter to reboot (maybe some early Escapes/Enters after a wait will be needed to clear error dialogue boxes before the shutdown) – does this invoke any reset sequence in LEDs on the board?

If you think it’s mainly a video issue

The fact that he says there’s no UART output suggests it could be something bigger than that.

Which UART were you looking at? UART3 is the one that all the current boards use for debug output. I’d assume that that’s the same as for the EVM board, but maybe it’s different.

Getting RISC OS up and running on the board should be fairly easy, just a case of tweaking a few bits in the HAL. Some time in the next day or two I’ll try and find the time to take a look at the EVM hardware docs and see if I can produce a build for you.

Sorry for the delayed response.

That’s the one, Trevor. (I’ve got a Revision G board (if the screening on the PCB is to be trusted) – albeit with a pre-installed TI WL1271 802.11/Bluetooth daughterboard), if it makes a difference).

Given that I’ve only just received a DVI-D/HDMI adapter, and need to find a USB keyboard, I haven’t had chance to see if I can get audio or video output working.

As for UARTs, I’m currently using UART1/2 (which is the default sink for at least U-Boot debugging output; and seems to multiplex UARTs 1 & 2 somehow), although I’ll have another go with UART3 later. If I quickly switch ports after issuing the final bootloader CLI command, all that I see in CuteCom’s output widget is a hexadecimal number (a port ID?).

If it helps, I’m currently using a spare 2GB SD card containing a copy of U-Boot/X-Loader from this page plus a “raw” RISC OS ROM image extracted from a recent BeagleBoard archive; and attempting to boot using the following commands:

mmc init

go 0×82000000


I’ve also attempted to substitute 0x82000000 for 0x81000000 in those commands, after cold-booting the board by unplugging the power cable, and then reconnecting it. The card’s partition table was prepared using the script supplied in that package; and I’m able to reliably boot two different Linux kernels (an Android one, and an Angstrom one) that I copied previously.

For a sector dump of that card, the GNU file utility reports:

dump2: x86 boot sector; partition 1: ID=0xb, starthead 32, startsector 2048, 1048576 sectors, code offset 0xb8

Prior to, and after issuing the aforementioned commands, I see:

\0x00

The boot process then seems to stall, at that stage.

I’ve also attempted to use a modified copy of the card containing Windows CE that shipped with the board (I just moved everything to a new “WINCE” directory, and copied over the “u-boot.bin” and “MLO” files from the Android package), and receive the same result.

The GNU file utility reports dump: x86 boot sector, code offset 0x0, OEM-ID "MSDOS5.0", sectors/cluster 64, root entries 512, Media descriptor 0xf8, sectors/FAT 236, heads 64, hidden sectors 135, sectors 3858489 (volumes > 32 MB) , serial number 0x61636637, unlabeled, FAT (16 bit) for a sector dump of that card.

I look forward to trying out your ROM, Jeffrey – but in the meantime, I hope that helps. :)

As for UARTs, I’m currently using UART1/2 (which is the default sink for at least U-Boot debugging output; and seems to multiplex UARTs 1 & 2 somehow), although I’ll have another go with UART3 later. If I quickly switch ports after issuing the final bootloader CLI command, all that I see in CuteCom’s output widget is a hexadecimal number (a port ID?).

I’d guess that since the EVM uses UART 1/2 for debug output, it doesn’t bother to initialise UART 3 at all. RISC OS does use currently UART 3 for debug output, but doesn’t bother initialising the port either, since (for all the other OMAP boards) the port will have already been initialised by x-loader/U-Boot. So when you connect via UART 3 you’re probably just seeing random garbage from the port not being initialised properly.

If you’re lucky you might be able to get USB & video working using the current build. But I wouldn’t be surprised if you’re not able to get anything working at all until I add EVM support to the ROM image.

That makes sense, Jeffrey.

Curiously, despite the “Quick Start Guide” in the box telling users to connect their RS-232 cable to UART3, prior to booting the Windows CE demo card, it appears that no debugging output is dumped there (although I think that I managed to get the client-side PPP implementation partially working on it).

Of course, that demo doesn’t seem to dump debugging output on UART1/2, either…

I wouldn’t be surprised if that’s the reason why Symbian^3 boots are mute/deaf, too – although that’s a matter for another venue. :)

That said, I’ve just tested the board’s USB EHCI Host port with my Nokia N73 in USB Mass Storage mode, and although my phone’s USB stack realises that it’s connected to a host, I don’t immediately see anything in U-Boot’s output to suggest that it’s capable of utilising it as a bootable device.

Additionally, it appears that video output via DVI doesn’t work, since the Samsung plasma TV in the lounge displays “No Signal” – which is what I expected, prior to testing, just now.

I realise that others are busy with more pressing matters, and I’m probably beating a dead horse now – but has anyone got around to investigating this, out of curiosity?

Between university; life in general; other projects; and a mobile software development contract, I haven’t had much time to do anything with RISC OS, recently. I suppose that not having a copy of the toolchain, or another RISC OS machine doesn’t help, either…

Thanks.

I suppose that not having a copy of the toolchain, or another RISC OS machine doesn’t help, either…

Suggestions for your Christmas list:

1. Raspberry Pi
2. DDE

I realise that others are busy with more pressing matters, and I’m probably beating a dead horse now – but has anyone got around to investigating this, out of curiosity?

It’s still lurking on my todo list, unfortunately. I’ll see if I can find the time to look at it tomorrow.

I’ve uploaded a ROM image here which should hopefully work OK on your EVM board. A few notes:

• It’ll use UART 1 for debug output, which as far as I can tell is the same UART u-boot uses.
• Load via ‘fatload mmc 1 0×81000000 riscos’ and start via ‘go 0×81000014’
• I’ve enabled the RISC OS debug terminal, so by default all keyboard input will be taken from the serial port, and text output will be echoed there as well
• Video (via the DVI socket) and sound should hopefully work
• The USB OTG port might work if you’re lucky, but I haven’t actually checked the docs to see if anything special needs doing compared to the other machine types
• The USB host port should work. Just remember that as with most other OMAP3 boards you’ll need to connect a hub to use low/full speed devices (keyboards, mice, etc.)
• The way that RISC OS’s debug terminal works means that whenever you’re at the command line (or any other single-tasking situation) it’ll ignore all keyboard input and only pay attentiont to the serial port. But if you enter the desktop then (assuming USB is working) any attached keyboard should work fine.
• This means the easiest way of checking if USB is working (particularly if video isn’t working) is probably to just attach something and then check the output of *usbdevices

Let me know how you get on. If video & USB are working then I can upload a build with the debug terminal disabled so you can make proper use of the machine.

remember that as with most other OMAP3 boards you’ll need to connect a hub to use low/full speed devices (keyboards, mice, etc.)

The BBxM being the obvious exception?

That and the TouchBook.

Hi Jeffrey,

Apologies for the delayed reply – and thanks for the ROM image. I’ve tested it on my board, and it appears that the boot process gets as far as the following, before stalling:

4194304 bytes read
OMAP3_EVM # OMAP3_EVM # go 0×81000014## Starting application at 0×81000014 …
OMAP3 HAL init
Board config=OMAP3 EVM
HAL_Init
Video_init
USB_Init
NVMem_Init
Timer_Init
Interrupt_Init
GPMC_Init
HAL initialised
InitCMOSCache entry
InitCMOSCache done
IMB_Full done
Keyboard scan complete


I’ve tried connecting USB devices, and also entering commands in CuteCom – to no avail.

Annoyingly, after performing a soft reset, the boot process then becomes stuck at NVMem_Init – which leads me to suspect that the contents of the board’s NVRAM have been corrupted, somehow.

Annoyingly, after performing a soft reset, the boot process then becomes stuck at NVMem_Init – which leads me to suspect that the contents of the board’s NVRAM have been corrupted, somehow.

Your NVRAM should be fine – At the moment the NVMem stuff just uses a file on the SD card rather than an EEPROM or NAND flash.

There have been a couple of reports of the NVMem code causing trouble recently. I’ll have a think about things and see if I can get another build uploaded later today.

I’ve uploaded a new ROM image that contains some fixes to the NVMem code. Hopefully that will allow things to run further for you, since there’s not much else that can go wrong between the keyboard scan completing and the next bit of text that’s output.

Thanks for the updated ROM.

I’ve just tested it, and was able to get to the keyboard scanning phase, after a cold boot – before seemingly hanging again (due to the lack of a connected USB keyboard?). However, subsequent warm, or cold boots seem to terminate after HAL_Init.

Curiously, after removing the SD card, and reinserting it into my laptop, it appears that the file system has been rendered to an inconsistent state, and multiple FAT links to a “CMOS” file seem to exist:

After performing an FS integrity check, erasing the offending files, and write-protecting the SD card, I’m finally able to return to the Keyboard scan complete state.

At this stage, I’m pretty much out of ideas, as far as potential causes of that issue are concerned.

I’ve also just realised that the status of the SD card’s write-protection switch is being ignored during the boot process – although I believe that its enforcement is done in an “informal” manner, at the SD controller driver level, in some cases.

Hmm, OK. When I get home I’ll upload a build with the CMOS write disabled, and I’ll have a go at recreating the issue on one of my beagleboards (presumably it’s an issue with how the filesystem is set up on the card you’re booting from – so if I download the Android boot image from Mistral’s site and then replace x-loader and u-boot with the BB versions I should be able to recreate it)

I’ve also just realised that the status of the SD card’s write-protection switch is being ignored during the boot process – although I believe that its enforcement is done in an “informal” manner, at the SD controller driver level, in some cases.

Correct. All the OMAP boards I know of use a GPIO pin to detect the write protect state, but I haven’t had the time to hook it up to the NVMem code yet.

I’ve uploaded a new build with the NVMem save code disabled. Fingers crossed it’ll work this time!

Thanks for the new ROM image, Jeffrey. After a bit of a false-start involving incorrect memory addresses – which mislead me into thinking that the ROM was defective, I now have a Supervisor prompt:

*


(Apologies for the ridiculously long and wide post – although I wasn’t quite sure of the best way to quote the screendump, without breaking indentation, or other vaguely useful characteristics).

For what it’s worth, USBDevices reports the following:

*USBDevices

Sadly, it doesn’t seem to detect a Western Digital external HDD, an ACS ACR122U smartcard reader, a Pinnacle 72e DVB-T receiver, or a ZTE UMTS modem connected to the EHCI Host port.

New build uploaded. I was able to reproduce the NVMem issues by using Mistral’s Android boot image, so the bugs that were causing it to fail to boot and create lots of CMOS files should now be fixed. I also spotted something that I’d missed from the USB initialisation, so with any luck the EHCI port should be working now.

Did you check if anything else was working? Sound, video, USB OTG?