Towards BeagleBoard "CMOS RAM"

Is it possible to build just the HAL on its own?

I’ve read that building RO takes about 45 minutes. I don’t like that as an edit/build/test loop time.

45 minutes (or thereabouts) is the time it takes to build the ROM from scratch. Subsequent builds (i.e. with just Make ROM, Install ROM and Join ROM ticked) will only take a couple of minutes, assuming you haven’t changed lots of files.

But if you do want to cut down on the ROM build time, then there’s a “MkRom” script in each HAL folder that will compile just the HAL, thus negating the need for the “Make ROM” step. There’s also a MkRomInst script in HAL.Tungsten which will build the HAL and then copy it to the RiscOS.Install folder (which is what the “Install ROM” step does). For some reason I don’t have that script in the OMAP3 HAL folder, but you should be able to use the Tungsten one after making a mintor modification (change “amu_machine rom debug ...” to “amu_machine rom _debug ...“). So if you use that script then all you’d need to do is run the Join ROM stage within !Builder.

Also, before running any of the standalone build scripts, make sure you’ve loaded up builder and selected the right build directory & environment. This’ll set up all the system variables that the build system relies upon.

OK, I’m building just the Make ROM, Install ROM and Join ROM stages after a successful build of RISC OS. I’ve added a module of code, NVMemory, to the Sources.HAL.OMAP3.s directory; I’ve added it to the makefile; I’ve removed the NVMemoryType routine from Stubs; in Boot, I’ve made all the HAL_NVMemory calls except IICAddress non-null, importing them from my new code. It all builds OK.

Originally I tried making NVMemoryType return 0xC3. Regardless of whether I made the Read and Write calls return 0 or 2048 (the size I declared), RISC OS doesn’t boot. From there, if I simply change NVMemoryType to return 0, it boots again.

I’ve declared the page size as 512 (because that’s the natural block size for SD and SDHC). I don’t yet know whether that’s a problem. I have not tried integrating my C at all yet, so there’s no attempt to handle the card at all.

So I have some progress, just not nearly as much as I had hoped for.

I guess a couple of things I can do are to reduce the page size and to make the read operation clear the requested block to 0. Any more ideas are welcome.

RISC OS doesn’t boot.

Define “doesn’t boot”. Do you get any debug output or does it just hang? Are you sure it isn’t crashing in the middle of your code (what little of it there is)? What’s the last thing that’s output before it does crash? You might be able to take a guess as to where it’s going wrong just by looking at what happens between that point and what it should print out next.

If you can’t work out what’s wrong then feel free to send me code/binaries. It won’t take more than a couple of minutes to find the cause of the crash with JTAG.

Define “doesn’t boot”.

After the orange screen, the screen is just black. There appears to be no text output to screen whatsoever.

And what does the serial port say? (Trying to debug HAL/OS initialisation without having access to the serial port will be practically impossible)

And what does the serial port say? (Trying to debug HAL/OS initialisation without having access to the serial port will be practically impossible)

I never did finish getting the serial port going.

Only update so far is that (Type = &C3, Size = 2048, PageSize = 1, ProtectedSize = 0, Read and Write both return 0) equally doesn’t boot.

B*gger. With all the swapping of SD cards, I’ve damaged one of the card connector’s pins. Now nothing will boot, of course.

B*gger.

You might notice that one of the card connector’s pins is damaged. If you have to, you could try a Return Merchandise Application I’ve no idea how long this would take though. And perhaps you’ve exceeded the 90 day limit.

If so, asking on the discussion group should hopefully lead to an answer about repairs outside this period.

Apart from morality considerations, I’ve had the card for much longer than 90 days.

Unfortunately this brings my work on “CMOS RAM” to a halt until I can replace either the connector or the board.

I’m going to attempt unsoldering the connector this lunchtime. That will be a significant challenge. However, if I can do it, soldering in a replacement will be easy by comparison. I’ll get on to the discussion group to see about a replacement connector.

I think they tend to be fairly generous with their RMA’s, so it might be worth checking first before you go desoldering the card connector.

But if you do decide to replace the connector, then you can find the bill of materials here.

There is good news – I have managed to do a repair. It’s at least temporary; if I take care with the board, it may last a long time. It was one of the row of pins nearer the mouth of the connector, which had got pushed all the way back. Fortunately it’s a less brittle material than I’ve seen on some connectors, so I was able to bend it back into a more normal shape and position. I won’t know for sure until this evening whether it works.

Unsoldering the thing completely, if I eventually have to do that, will be a nightmare.

(On the basis that you win some, you lose some: yesterday I opened up my Renault electronic car key, whose Lock button had failed. I resoldered the switch this lunchtime, but, under the microscope, I discovered that I had damaged an unusual component in the process of opening it up, so that will be up to GBP130 for a new key, I suppose.)

Dave, if you need to unsolder the card holder first try to cut every pin you can reach and unsolder these wire by wire afterwards. The card holder is damaged anyway. Sorry for your car key.

Dave, if you need to unsolder the card holder first try to cut every pin you can reach and unsolder these wire by wire afterwards.

Yes, that was always our production department’s favourite way to remove SMDs. But have you looked behind the SD connector and seen how close together those leads are? Do you possess a pair of cutters that will get in there? I don’t. I know they exist, but at quite a price.

Anyway, the good news is that my repair this lunchtime worked. The BeagleBoard lives! I’m posting this message from it.

The BeagleBoard lives!

Hurrah! And sorry for my slightly unscrupulous previous posting.

Do you possess a pair of cutters that will get in there?

Nope. I generally use a sharp knife only. It looks as not being for the faint-hearted, but works very well.

And what does the serial port say? (Trying to debug HAL/OS initialisation without having access to the serial port will be practically impossible)

Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Error: reading boot sector
Loading u-boot.bin from nand

U-Boot 2009.11-rc1-00601-g3aa4b51 (Jan 05 2010 - 20:56:38)

OMAP3530-GP ES3.1, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MB
NAND:  256 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
Board revision C4
Die ID #5268000400000000040365fa12012015
Hit any key to stop autoboot: 10  9  8  7  6  5  4  3  2  1  0 
mmc1 is available
reading boot.scr

120 bytes read
Running bootscript from mmc ...
## Executing script at 82000000
reading riscos

4194304 bytes read
## Starting application at 0x81000000 ...
OMAP3 HAL init
Board config=BeagleBoard
HAL_Init
HAL initialised
InitCMOSCache entry
InitCMOSCache done
IMB_Full done
Keyboard scan complete
FIQ enabled
IRQ enabled
VduInit
ExecuteInit
Machine ID duff,zero substituted
KeyInit
MouseInit
OscliInit
Enabling IRQs
IRQs on
Debug terminal on
HAL_InitDevices
HAL RTC detected!
Leaving LookForHALRTC
InitVariables
AMBControl_Init
ModuleInit
init mod UtilityModule
init mod PCI
init mod FileSwitch
init mod ResourceFS
init mod TerritoryManager
init mod Messages
init mod MessageTrans
init mod UK
init mod WindowManager
init mod Desktop
init mod SharedCLibrary
init mod OMAPVideo
OMAPVideo: 
OMAPVideo: ***** Debug Session Started **************************************
OMAPVideo: DebugLib is (c) Pace Micro Technology plc. 1997-2001
OMAPVideo: System: DebugLib 0.65
OMAPVideo:         remotedb 0.10
OMAPVideo:         PDebug 0.07
OMAPVideo: Task:   OMAPVideo
OMAPVideo: Time:   Fri Jan  2 00:00:00 1970
OMAPVideo: Levels: Not specified.
OMAPVideo: ******************************************************************
OMAPVideo: Using DMA channel at f9e56c20
OMAPVideo: dss_reset
OMAPVideo: Finished module initialisation, DSS regs=f9e50000
init mod TaskManager
init mod ARM
init mod BASIC
init mod BASIC64
init mod BASICTrans
init mod BufferManager
init mod ColourTrans
init mod Debugger
init mod DeviceFS
init mod Portable
init mod RTSupport
init mod USBDriver
init mod EHCIDriver
init mod MUSBDriver
init mod DisplayManager
init mod DMAManager
init mod DragASprite
init mod DragAnObject
init mod Draw
init mod BBCEconet
 error: No 'Econet' installed
init mod FileCore
init mod RamFS
 error: RAM disc size too small
init mod Filer
init mod FilerSWIs
init mod FSLock
init mod FontManager
init mod FPEmulator
init mod VFPSupport
init mod Free
init mod Hourglass
init mod IIC
init mod International
init mod InternationalKeyboard
init mod InverseTable
init mod NetFS
 error: No 'Econet' installed
init mod NetFiler
init mod NetPrint
 error: No 'Econet' installed
init mod NetStatus
init mod NetUtils
init mod Obey
init mod Pinboard
init mod PipeFS
init mod RAMFSFiler
init mod ResourceFiler
init mod ROMFonts
init mod ScreenBlanker
init mod ScrSaver
init mod ShellCLI
init mod SoundDMA

That’s where it hangs. I haven’t made any changes to the SoundDMA code (not consciously, anyway!).

The above was built with this NVMemory file:

; NVMemory* functions

        GET     Hdr:ListOpts
        GET     Hdr:Macros

        AREA    |Asm$$Code|, CODE, READONLY, PIC

        EXPORT   HAL_NVMemoryType
        EXPORT   HAL_NVMemorySize
        EXPORT   HAL_NVMemoryPageSize
        EXPORT   HAL_NVMemoryProtectedSize
        EXPORT   HAL_NVMemoryProtection
        EXPORT   HAL_NVMemoryRead
        EXPORT   HAL_NVMemoryWrite

HAL_NVMemoryType
        MOV     a1, #&C3 ; Bytes 0..15 readable and writeable,
                         ; HAL provides access calls
        MOV     pc, lr

HAL_NVMemorySize
        MOV     a1, #2048 ; 2 kiB
        MOV     pc, lr

HAL_NVMemoryPageSize
        MOV     a1,#1   ; Try it tiny
        MOV     pc, lr

HAL_NVMemoryProtectedSize
        MOV     a1, #0  ; No protected memory
        MOV     pc, lr

HAL_NVMemoryProtection
        MOV     pc, lr  ; No memory protection, nothing to do

HAL_NVMemoryRead
        ; Return the number of bytes requested
        Push    "a1-a4" 
        MOV     a4, #0
10      STRB    a4, [a2], #1 ; Clear a byte, bump the pointer
        SUBS    a3, a3, #1
        BGT     %BT10
        Pull    "a1-a4" 
        MOV     pc, lr

HAL_NVMemoryWrite
        MOV     a1, #0  ; Return 0 bytes written for now
        MOV     pc, lr

        END

and the IICAddress function is not implemented, so remains a NullEntry in s.Boot. The other functions are implemented, and I’ve just checked again that they are implemented in the correct order, i.e. I’ve not got the HAL function call numbers wrong.

Let me try that again – the type should be &C03, not &C3…

... and it works infinitely better like that.

My apologies for the noise.

Let me try that again – the type should be &C03, not &C3…

Yes, I was just about to say that :)

But before you start running into any further problems, I’d suggest changing the code to use a RAM cache instead of just making all reads return zero. Plus your current HAL_NVMemoryRead implementation is returning the wrong value anyway (it should return a3, not a1).

To get a RAM cache working, do the following:

1. Add the following to hdr.StaticWS, just before the HAL_WsSize line:

NVRAMCache # 2048

2. Add a few extra GET directives to s.NVMemory:

GET Hdr:OSEntries
GET hdr.omap3530
GET hdr.StaticWS

3. Change your read & write functions for these:

HAL_NVMemoryRead
        ; Return the number of bytes requested
        Push    "a3,lr" 
        ADR     ip, NVRAMCache
        ADD     ip, ip, a1 
10      LDRB    a4, [ip], #1
        STRB    a4, [a2], #1
        SUBS    a3, a3, #1
        BGT     %BT10
        Pull    "a1,pc" 

HAL_NVMemoryWrite
        ; Return the number of bytes requested
        Push    "a3,lr" 
        ADR     ip, NVRAMCache
        ADD     ip, ip, a1 
10      LDRB    a4, [a2], #1
        STRB    a4, [ip], #1
        SUBS    a3, a3, #1
        BGT     %BT10
        Pull    "a1,pc"

Also note that if you’re copying & pasting from NetSurf, you’ll end up with a load of hard spaces instead of regular spaces, so some search-and-replace may be necessary.

Also when building the code after changing hdr.StaticWS, be aware of the dependency tracking bug with versions of AMU prior to 5.28 – so you might want to delete the contents of the ‘o’ folder to make sure everything gets rebuilt.

Thanks, Jeffrey, that all seems to work plausibly; except…

It looks as if NVMemoryRead gets called 2048 times on startup. (I can’t be certain that it’s really 2048 because characters start to get lost, but there are over 1700 debug lines, and I’m declaring a size of 2048 bytes, so it seems a reasonable guess.) This applies for page sizes that I’ve tried of 1, 512, 256 and 16. Is that what you would expect?

I tried a simple change of setting !Alarm’s choices to a display format of “User defined”. I can read the NVMemory contents before and after the change, and I can see two changed bytes (presumably one is the checksum). So far, so good. But I had expected that the change would persist over a reboot with power maintained; would you?

It looks as if NVMemoryRead gets called 2048 times on startup. (I can’t be certain that it’s really 2048 because characters start to get lost, but there are over 1700 debug lines, and I’m declaring a size of 2048 bytes, so it seems a reasonable guess.) This applies for page sizes that I’ve tried of 1, 512, 256 and 16. Is that what you would expect?

RISC OS does build its own RAM-based cache of the CMOS RAM contents, so that’s why there are lots of reads on startup. I haven’t really looked at the code in any detail, but if it’s making 2048 read requests (irrespective of the page size) then I’d guess that the code isn’t smart enough to know that each read operation actually fetches an entire page instead of a single byte. So that’s probably something that needs improving if you’re planning on having a big cmos.dat file, or if you’re thinking of not having an extra layer of caching inside the HAL.

But I had expected that the change would persist over a reboot with power maintained; would you?

The HAL clears all RAM on startup, so I wouldn’t expect anything to be maintained.

I haven’t really looked at the code in any detail, but if it’s making 2048 read requests (irrespective of the page size) then I’d guess that the code isn’t smart enough to know that each read operation actually fetches an entire page instead of a single byte.

Actually, looking at the HAL_NVMemoryPageSize docs, it only mentions that the page size affects the behaviour of HAL_NVMemoryWrite. So it probably is the case that the code is too dumb to know that it could read multiple bytes at once.

The HAL clears all RAM on startup, so I wouldn’t expect anything to be maintained.

That would explain it. Thanks!