Error booting latest downloadable Beagle ROM

I just tried to build the OMAP ROM on Beagleboard. It nearly works. The squash module causes an abort at &FC28AD24.

It would be great if we could get the Beagle Board to build it’s own ROM. I’ve been using my Risc PC, it takes just over 3 hours to complete!

Has anyone tried that? I can’t think of many reasons why it wouldn’t work. The latest C tools have been built to be ARMv7 safe (as well as generating ARMv7 safe code themselves) so should be able to run on the Beagleboard.

I think that is what Chris was trying to do, but got the abort from the squash module.

I was. It looks like everything compiled OK. Took about 35mins. Just using the squeeze command on any file triggers the abort.

Not related to this. I get an abort if I save the ‘Desktop Settings’ from the Task menu. &FC1D6ADC in module filer. Then on boot up I get an abort &FC1696CC in ADFSFiler. It goes away if I delete the !Boot file the save creates.

Could someone do a *memoryi around the address of the abort in Squash so I can look into it?

I just know that the problem is going to be something to with Squash being a binary blob. I bet it’s been built to take advantage of ARMv7-style unaligned loads, and since unaligned aborts are currently enabled, you get the abort.

The Squash module is one of those irritating modules we haven’t been able to release the source for yet. We can’t track down the copyright holder, so it needs the source files that implement the LZW algorithm replacing with an open source implementation – say that from Unix “compress”. We’ve never found time to do that at ROOL, are there any volunteers out there that could take this on?

The abort also happens with alignment exceptions turned off. The version of perl the build uses aborts with them turned on.

I tried posting the output of memoryi but I get an internal server error when I save the reply. Is it ok to email it instead?

Sure. Email away to info@riscosopen.org.

As for the Squash module sources, it also includes some assembler sources which look at first glance to me like they might end up doing unaligned loads. I don’t think it’s as simple as the binary blob having been built with the compiler taking advantage of unaligned loads.

I’ve found if I click menu over the USB stick icon and click ‘Backup’ I get ‘Internal error’, ‘Branch Though Zero’. Then ‘filecore in use’. Only a reboot clears it.

The Squash module is one of those irritating modules we haven’t been able to release the source for yet. We can’t track down the copyright holder [snipped]

Didn’t TBAFS use a similar algorithm? (Possibly not contactable either though.)

I think the failing code is handwritten assembler, possibly generated from a macro. There are 3 occurrences of the instruction pair:

LDMIA R7,{R11} ANDS R8,R4,#&1F

(You can just search for the first instruction, there are no other matches). If you replace each occurrence with the following:

ANDS R8,R4,#&1F LDRNE R11,[R7,-R8,LSR #3]!

you will find that Squash now works with or without alignment exceptions. The code was indeed merging a token into one/two words at an arbitrary bit offset and relying upon LDMIA and STMIA ignoring the bottom 2 bits of the address. The change avoids unaligned loads and will work on other CPUs too.

Hope this allows you to fix it.

Thanks to Adrian’s fix the build now gets further.

The grep command supplied with the build doesn’t run on beagleboard.

I guess this might be the relatively old version from the ROOL sources. I’ve just compiled the latest, try this:

http://www.riscos.info/downloads/packages/UtilitiesDetails.html#grep

I got another error ‘Cannot open syms.A_Entries1 for I/O redirection’ with the updated egrep command.

Running the egrep command manually worked. I then removed the failed command from the Makefile. Reran the !Builder and out popped a working rom image! Takes about 31mins.

Chris: I’ve tracked down and sent Fred a fix for the StrongED TaskWindow problem. StrongED now seems happy on my BeagleBoard. It wouldn’t be home without it. :)

Adrian, could you please add these fixed versions to the CortexA8 Software compatibility list so others can access them? (I feel the same about StrongED ;-)

Adrian: Many thanks for taking the time to look into this but you might want to check with me first next time as I’d already fixed my local copy – Chris had responded by private email.

I’m hoping to release a new alpha version of StrongED (4.69a1) soon so that the fixes can be tested by a wider audience, especially on the BeagleBoard.

Hopefully no-one minds my asking – this isn’t reallty ROOL related – but how well does StrongED work on the BeagleBoard? One of my concerns is that there’s still some self-modifying in there. Also direct screen access isn’t something that’s guaranteed to work.

Okay, no problem. It didn’t take much time, and the result is that StrongED is working for me (yay! No more Edit!), making the BB much more usable, and I can do so more testing for you too.

It seems fine so far. Screen access works as on earlier platforms, and provided that the self-modifying code is protected with calls to OS_SynchroniseCodeAreas it should function. Of course, it’s usually undesirable from a performance perspective nowadays, but that’s a separate point.

It’s good to see progress is being made with StrongEd.

There are a few issues with StrongEd on Beagleboard. I can send a list or wait for the alpha version.

Adrian: Good to hear that StrongED is performing well. Yes, the self-modifying code is undesirable and I already know how to remove it but its removal, in this case, may lead to a performance drop. I suppose I should just try it and see.

Chris: If you could send me the issues that you’ve found then I’ll see if they’re still present in my local copy and if so fix them before releasing the alpha version.

I’ve found another abort. Creating a ram disc with alignment exceptions turned on causes an abort at &FC1CEF74 in module FileCore. The Task icon also disappears.

I just tried to build a rom from the latest OMAP source.

VideoDevice appears to be missing from ‘Source.Kernel.Makefile’. At least adding it makes the build complete successfully. On trying to boot the rom I get ‘Undefined Instruction at &FC004540’.

Should be fixed now – I guess I didn’t test those changes as much as I thought I did!

With the latest rom build the date and time isn’t getting set on boot up. If I reboot with a previous rom build the date and time is set correctly.