Tips 'n' tricks for the OMAP port

I thought it would be a good idea to consolidate any instructions and any tips in one thread.

Networking

Place the EtherUSB module in System:Modules.Network and then create an obey file with the following,

Set InetSetup$Driver$USB EtherUSB:ej0:EtherUSB:0.06:EtherUSB

Then put the Obey file in !InetSetup.Autosense.

The following Three tips need the source to be recompiled after.

Default Filsystem to SCSI

FileLangCMOS, 26

(SCSI Filesystem number)

Boot to desktop

LanguageCMOS, 10

(The Desktop module position in ROM)

Change Desktop Boot Banner

The sprite used for the banner is located at Sources.Desktop.Desktop.Resources.UK.Iyonix.Sprites

Turn Off Alignment Exceptions

Use the following as a BASIC program

DIM code% 256
P%=code%
[ OPT 0
SWI ”OS_EnterOS”
MRC CP15,0,R0,C1,C0,0
BIC R0,R0,#2
MCR CP15,0,R0,C1,C0,0
MSR CPSR_c,#&10
MOV R0,R0
MOV PC,R14
]
CALL code%

Edit Sources.Kernel.s.NewReset Line 1067 Change to FileLangCMOS, 26 (SCSI Filesystem number)

Edit Sources.Kernel.s.NewReset Line 1097 Change to LanguageCMOS, 10 (The Desktop module position in ROM)

Excellent!

When I get a chance I’ll edit the kernel to use those options by default – it should make things a lot more user-friendly until we’re able to get the CMOS/NVRAM support added.

Some info on the DevKit8000

1. Address Register at offset &0
2. Data Register at offset &400
   The IRQ line is tied to GPIO 25
   

1. GPIO 153 = LED B
2. GPIO 163 = LED 2
3. GPIO 164 = LED 3
4. GPIO 186 = LED 1

The User button is connected to GPIO 26

I have communicated with the DM9000, but not having any C/C++ skills, I don’t think I can write/convert the requisite Ether driver.

I have got as far as enabling the chip, and it shows the line is active by the LED’s. I have written routines to access the registers, read/write the MAC and read/write the PHY, in assembler as a module.

Edit Sources.Kernel.s.NewReset Line 1067 Change to FileLangCMOS, 26 (SCSI Filesystem number) seems to work. But then during autoboot I get a message “disk is empty”. Pressing ‘Retry’ will reset the beagleboard and returns to the same message. Pressing ‘Cancel’ gets me the desktop and the disk appears to be readable. Did I miss anything here to get RISC OS to autoboot from the SCSI disk?

I think the problem you’ve experienced is due to the built-in delay of 4 seconds between SCSISoftUSB detecting the device and registering it with the main SCSI driver (See the PopUpDelay #define in Sources.HWSupport.SCSI.SCSISoftUSB.c.module)

This is also the main reason why I haven’t yet submitted Tank’s changes – I’m planning on modifying SCSISoftUSB so that there’s no delay when you’re outside the WIMP (to make sure booting works), and to make the in-WIMP delay configurable.

I guess the reason the delay exists is to give people time to sit up straight and focus on the screen before the icon appears – but in my case I’ve got a USB extension cord on the desk right infront of me, so I don’t appreciate any extra delays that add to the tedium of building and testing Beagle ROMs!

Thanks Jeffrey!

I first tested with #define PopUpDelay 0 but that would disable the detection completely. Setting it to 10 makes the beagleboard continue booting from the USBstick and I now can simply reboot and don’t need to type ‘scsi’ and ’!boot’ anymore :-)

Thanks again! you’re the best!

= ScsiFsCMOS, 2_100001

to Sources.Kernel.s.NewReset (I placed mine just after the FileLangCMOS entry.

This sets the default drive as 4 and 1 disk for the SCSI system.

Now that the new video module has been added to the OMAP build it’s possible to push the resolution a bit higher.

Here’s an MDF I came up with which works well on a 24in 16:10 LCD. I’ve been using it for a few days without any ill effects. It requires an OMAP rom built after Feb 28th.

# 1600×1000 (45Hz)

startmode

mode_name:1600×1000

x_res:1600

y_res:1000

pixel_rate:86000

h_timings:32,108,14,1600,0,98

v_timings:5,16,0,1000,0,0

sync_pol:3

endmode

At long last, I’ve now tweaked SCSISoftUSB’s “PopUpDelay” code and submitted the new version to CVS, along with a change to make SCSIFS the default filing system fro the OMAP ROM. So if you’ve got a card reader/USB stick connected with a boot sequence on it then it should now run the boot sequence and go into the desktop. I’m not sure what happens if you’ve got a USB hard drive connected – presumably you’ll still have to do this tweak to get it to boot. And if you don’t have anything connected, it’ll just leave you at the supervisor prompt, just like before (This is easily fixable as one of Tank’s tweaks shows, but it’s still much more convenient for me to be left at the command line than in the desktop)

For the SCSISoftUSB changes – the “pop up” delay that’s used when inside the WIMP can be configured using *SCSISoftUSB_PopUpDelay. When you’re outside the WIMP it will use a delay of 1cs, so device registrations with SCSIFS will essentially be immediate. This change, along with a fix to the regisration code¹, seems to be enough to get my beagleboard to reliably run the boot sequence on boot.

¹ It was registering the device with SCSIFS from within a ticker event (i.e. interrupt handler), which could then result in the registration failing since SCSIFS would be unable to grow the RMA from the IRQ. Now it does the registration from within a callback instead.

Also, all the “safe” bits of the video driver tweaks have been checked in, so people who want all the latest fixes needn’t worry about grabbing the sources from the ROM I uploaded.

Great stuff! And well in time for the Wakefield show too :-)

it’s still much more convenient for me to be left at the command line than in the desktop

Perfectly understandable and it’s good for ppl to know of Tank’s tweak. I see that HAL_KbdScan (which AIUI isn’t called at the moment) is able to check a number of keys. Didn’t RISC OS previously check for numpad-* for booting to the Supervisor prompt? Is there scope for this (or something similar) to be considered for inclusion at some point in the future?

I see that HAL_KbdScan (which AIUI isn’t called at the moment) is able to check a number of keys. Didn’t RISC OS previously check for numpad-* for booting to the Supervisor prompt? Is there scope for this (or something similar) to be considered for inclusion at some point in the future?

Yes, there’s definitely scope for getting it working. Unfortunately it’s not something that’s very easy to do, because it would require the HAL to have its own standalone copy of the USB drivers. Once things get further along (probably once we have CMOS RAM/NVRAM working) I might try proposing a few different ideas to ROOL on how to make the keyboard scan easier to support, e.g. moving the check to just after the ROM modules have been initialised, so that RISC OS can do the check itself without relying on code in the HAL. The main issue with any change like that would be handling the CMOS reset keys – you’d need to be sure that no matter what the CMOS RAM settings are, the OS can’t die before it reaches the keyboard scan.

Does anyone know of ROL have made any changes in this area for RISC OS 6/Adjust? I know they’ve done a fair amount of stuff to prettify the startup sequence, but I’m not sure whether any of their changes would have involved changing the process so that it relies on the real keyboard drivers instead of bespoke code in the kernel/HAL. (Of course, IIRC the A9 doesn’t support saving of CMOS RAM settings yet – perhaps it’s their way of dodging the problem!)

Having decided to try a wireless multimedia keyboard with inbuilt trackball on my Devkit board, only to realise there is no menu button, I thought I would make the menu key on the keyboard produce the menu button code. To do this you need to edit the Sources/HWSupport/USB/NetBSD/build/c/usbkboard file.

Look for the mapping_table array and change the KeyNo_Menu entry to read KeyNo_CentreMouse.

For any IGEPv2 users out there using EtherGEP, you can configure InetSetup to use it by adding an obey file (called anything, but “EtherGEP” would make sense) into !InetSetup.Autosense with the following in it:

Set InetSetup$Driver$NIC EtherGEP:eg0:EtherGEP:0.31:EtherGEP

Then put the EtherGEP module in System:Modules.Network.

EDIT: EtherGEP is now up to version 0.45. In short, always check for the latest version from Stephen Leary before carrying out these instructions.