uart2 memory address error

I have been trying to use uart2 on the beagle board without much success using the os_hardware calls.
I then wrote some software to directly access the port and could read and write OK.

This lead me to look at the sources and I found the following file castle/RiscOS/Sources/HAL/OMAP3/hdr/omap3530
which has the following :-

L4_Core            *        &48000000
L4_Wakeup          *        &48300000
L4_Per             *        &49000000

L4_UART1           *      L4_Core+&6A000 ; UART 1 (address OK)
L4_UART2           *      L4_Core+&6D000 ; UART 2 (address should be &6C000)
L4_UART3           *      L4_Per+&20000  ; UART 3 (Address OK)

I looked at SPRUF98U.pdf which says :-

UART1 0x4806 A000 1K byte
UART2 0x4806 C000 1K byte
UART3 0x4902 0000 1K byte

I then loaded my riscos image into !zap and changed 5 4806d000 to 4806c000 and now I can access the ports using os_hardware calls
the strange thing is HALUARTStartUP does not seem to startup the port correctly
I have to program the baud rate by and start the port by:-

setting bit 7 of the LCR_REG
then write to DHL,DLL
reset bit7 of the LCR_REG

and then I write 0 to MDR_REG1

I can then access any serial port OK once it is started up with the above, so it seems that the address need changing to 4806c000 instead of 4806d000 in castle/RiscOS/Sources/HAL/OMAP3/hdr/omap3530

It may be that the HALUARTStartUP problem will correct itself once the address is changed.

Thanks for pointing this out. I’ve just checked in a few serial-related changes, which should show up in a new ROM image in the next day or two:

• Fixed the incorrect UART2 address
• Fixed the HAL UART functions to obey the UART programming rules laid out in the TRM. As far as I can tell everything is working OK, but the only thing I’ve currently got to test with is the basic two wire UART 3, so it’s possible that the flow control settings aren’t fully working.
• Changed the order in which the UARTs are exposed to RISC OS. Now HAL UART 0 is OMAP UART1, HAL UART 1 is OMAP UART2, and HAL UART 2 is OMAP UART3 (Previously OMAP UARTs 1 and 3 were swapped, under the assumption that OS_SerialOp would be using HAL UART 0 – but OS_SerialOp isn’t quite working yet)
• Added the DualSerial module to the ROM image

So although I haven’t got OS_SerialOp working yet, you should now be able to interact with the serial ports using the devices that the DualSerial module creates in Devices:$. Devices:$.Serial1 will be OMAP UART1, $.Serial2 will be UART2, etc. In theory you should also be able to use the internal32 serial block driver, but I haven’t tested that. You can still use the HAL calls directly if you want, but you may have to kill one or all instances of the DualSerial module in order to stop them interfering with the port settings (Note that DualSerial will actually show up as ‘Serial’ in the module list).

Another thing to note is that the DualSerial module will set the baud rate of each port to 9600bps (or thereabouts) on startup. This will cause issues for anyone (such as myself) who often uses HAL_DebugRX/HAL_DebugTX for debugging, since the default baud rate used by u-boot is 115200bps. I think the cleanest workaround for that is to either unplug DualSerial, or build a custom ROM that has the module removed, or edit HAL.OMAP3.s.board so that UART3 isn’t exposed to RISC OS (edit the UARTs column of BoardConfigTable).

Let me know if you’ve got any ideas for how things could be done differently – I realise that what I’ve done here is a bit above and beyond what your bug report required. But since it was easy to go from “working HAL API” to “entries in DeviceFS” I figured it was worth it to expose the UARTs through one of the traditional RISC OS interfaces instead of just the HAL one. Still on my todo list is to get OS_SerialOp working (as discussed here).

Another thing to note is that the DualSerial module will set the baud rate of each port to 9600bps (or thereabouts) on startup.

Wouldn’t it make more sense to modify the DualSerial module to initialise the baud rates to 115200? Who uses 9600 these days?

In my experience, 9600 is something like the common default for many devices. My last encounters were various satellite receivers and my Amplifier.

However, on RISC OS it should really be initialized with the configured speed.

Thanks for the update to the UARTS I will download the updated ROM soon.
Just out of interest I am using 300 baud, as I am only transmitting 4 bytes at a time!
Most of our devices here use 9600 for the interface speed scopes, spectrum analyzer, frequency counters etc.

If you want to try out a new ROM with Jeffreys latest fixes, I’ve built one from last nights CVS.

OMAP3 ROM Download Link

I have downloaded the OMAP ROM for the link above(thanks Rob)
If I RMKILL all instances of the DualSerial module then using HAL calls directly work OK.

Where would I find more information about accessing the serial port using Devices:$.Serial1 type commands I can find General information about DeviceFS but not how to access the serial port pins (cts line etc)

It looks like this is the specification for the DeviceFS interface.