SD Card Filer

Surprise surprise, new daily ROMs for all but not for OMAP3. No test today ;-)
But the second one is the MDF configure changed automatic. Only on my SDFS SD with a HD-Image from 14.07. The very older Bootcard works with the old configure without changing. The changes are only with the two (?) latest ROMs on the Pandora.

Surprise surprise, new daily ROMs for all but not for OMAP3

Yes, that’s because the build failed. This is what happens for odd-numbered ‘beta’ versions of RISC OS, I’m afraid.

It was actually my Pandora change that broke the build – sorry to everyone else! Better luck tomorrow…

Bad news today.
The new Pandora do nothing after loading and the following blank screen. It is also with the 19.07.ROM. I test this last days only with the old one. Sorry.
The old Pandora print the following line with the today ROM: “Init mod SDFS Error: DataAbort: Abort on data transfer at &FC2C3FBC (Error number &80000002)”

Many thanks.

P.S.: First edit: Any test with a external keyboard.
Only the sdfs cards are present.
*desktop after the error works.
Modules: Only sdiodevice are present. No sdfs. No icon on the iconbar.
sdiodevices und sdioslots give the one line for the left slot.

Restart with a other cmos and a present bootstick and sdfs card (with the removed is the same):
Boot break after the error message.
*cat give “No directory found”
*SCSI and *Cat give the right directory
*!Boot give “Error: X-file not found”
*Desktop and doubleklick to the device icon give “Abort on instruction fetch at &206E6F6C” after ok the FilerWindow is open and I can use the programs.
“First line” give only 0, the “HAL line” give the known long number and “device detect tool” works ok.
No sdfs module and no icon.
Al this with the old Pandora.

Part of me is beginning to wish I hadn’t started this, trying to debug a hardware driver when you don’t have the hardware is never easy!

This abort appears to be in SDIODriver, file c.device, line 78. This is the first time it tries to access the “slotinfo” array.

Can you try *ShowRegs please? I am particularly interested in these registers:

• R4 (pointer to HAL device)
• R1 (pointer to slotinfo array)
• R6 (slot number)

I understand you’ve been and I expect sooner with these words. I am very grateful and hope I can also help sometimes.

ROM 1907
*showregs
Register dump (stored at &2000B0F0) is:
R0 = 00000000 R1 = 00000000 R2 = 00000000 R3 = 00000000
R4 = 00000000 R5 = 00000000 R6 = 00000000 R7 = 00000000
R8 = 00000000 R9 = 00000000 R10 = 00000000 R11 = 00000000
R12 = 00000000 R13 = 00000000 R14 = 00000000 R15 = 00000000
Mode USR26 flags set: nzcvqjggggeaift PSR = 00000000
*

ROM 2107
*showregs
Register dump (stored at &2000B0F0) is:
R0 = FA207D94 R1 = FA207D98 R2 = 00000066 R3 = FA207D94
R4 = 00000001 R5 = 000010BC R6 = 000000FF R7 = 6C707061
R8 = 74616369 R9 = 00000000 R10 = 00000045 R11 = 20092D3D
R12 = 00000000 R13 = FA207DAC R14 = FC0280B0 R15 = 206E6F6C
Mode SVC32 flags set: NzcVqjggggeAifT PSR = 90000133
*

Help this?

That’s good, but I need the output of *ShowRegs after the “Abort on data transfer at &FC2C3FBC”, because “Abort on instruction fetch at &206E6F6C” has overwritten the register dump. If you have a USB drive, you can save it there by using

*ShowRegs { > SCSI::0.$.ShowRegsOutput }

I wonder how long it will take for Jeffrey’s board to arrive? It might be better if I disable the second slot again until he can help debug it – then at least Pandora will have a ROM that will boot :-(

I hope this is better…
(I used the *spool command. The output before and after was the same.)

Register dump (stored at &2000ADF0) is:

R0 = 00000000 R1 = EAFFFFF7 R2 = 000001FC R3 = EAFFFFF7

R4 = FC0255E4 R5 = 000001FC R6 = 00000000 R7 = 00000000

R8 = 00000000 R9 = 00000001 R10 = FA20021C R11 = FA207EA8

R12 = 00000000 R13 = FA207E70 R14 = 60000193 R15 = FC2C3FBC

Mode SVC32 flags set: NzCvqjggggeAift PSR = A0000113

The 1807-ROM works with the new Pandora…

Many thanks.

OK, what was happening was that R4 was being corrupted. I have just put a fix into CVS. This time I have tested it with my beagleboard+zippy, but changing the code so that it thinks it is a Pandora (except for the card detect and write protect, which are connected differently). This worked, so I am fairly confident it might work this time (press thumbs!)

Thank you. That means tomorrow in the ROM? Or can I even test an earlier ROM? Download, mail? I am not currently able to build me a ROM.
From tomorrow I will go back to work and free time is even less.
I will press my thumbs until blood comes.

Raik, I’m building you a ROM now.

Here you go! – http://robheaton.co.uk/riscos/roms/OMAP3Dev.5.19.zip

Sorry. Two ROMs three Errors…

Error 3: Accu down…

E1: Robs ROM: Breaks after Init mod Percussion Error: NosuchSWI1: SWI &%0 not known (ErrorNumber &1E6)

E2: Bens ROM: Init mod SDS Error: Undefined Instruktion: Undefined Instruction at &FC2CB424 (Error Number &80000000)

For both: No actions with the external Keyboard possible. Sorry no Regs…

I checked out the OMAP3Dev Sources from the CVS and built the ROM, I didn’t make any changes.
Ben will have to answer this one!

I was just trying to help…

I’m very thankfull for this.
I interested in is “your” bug a new Pandora problem or is this one for all?
I can test this tomorrow morning on my beagle but this is to late for the daily ROM.

The ROM I built runs fine on my BeagleBoard-Xm

Bens ROM also run an my BeagleBoard xM. Only a Pandora-Problem.
Many Thanks.

I am trying to prepare an SD card for use with a Raspberry Pi and am running into a few problems (caused by my lack of knowledge). I have partitioned the card with an initial DOS partition that has the necessary files needed to boot the Pi, plus the RISC OS image. If I insert the card and turn the Pi on, it will boot to a Supervisor prompt, and I can then type “Desktop” at the prompt and RISC OS will successfully load the desktop for me.

The card has an additional partition for RISC OS, which is for the time being another DOS one, as I’m not aware of any way of creating an arbitrary partition type using a Mac (apparently RISC OS is type 0xAD).

The SDFS filer displays the initial DOS partition in the icon bar, with the boot files and RISC OS image on it. Does this mean that the filer will only display the first partition on the device (as RISC OS has no partition support)? I tried formatting the card so that the partition for RISC OS was first, but the Pi refused to boot.

Looking at the partition map for Chris Hall’s RISC OS image, the boot partition is first on the image, followed by a larger one for RISC OS. How does this work?

So, how do I get the SDFS filer to ignore the initial DOS partition and let me format the second partition using HForm and install the RISC OS hard drive image on to it?

Any advice (Ben?) would be appreciated.

@ Ben
Pandora goes to work and then the big surprise. The ROM of today works with two SD cards on the Pandora. What was wrong with yesterday’s test Roms?
Unfortunately I only had time for a very short test, but he was very well.

Thank you very much!

@ John K.
I have done differently around. The first partition large ADFS first under RISC OS, and then the second small FAT under Linux and watch out that the ADFS area are free (unused) is.
The bootloader ignored the ADFS-Partition and RISC OS can only see the First.

Pandora goes to work and then the big surprise. The ROM of today works with two SD cards on the Pandora.

Hooray!

What was wrong with yesterday’s test Roms?

I have no idea. Like Rob, I just built the latest sources from CVS, and it worked fine for me on a beagleboard. The address you reported as causing an undefined instruction is not an undefined instruction for me. Because the ROM is protected from writes while the OS is running, the most likely cause is that the ROM was corrupted somehow on its way to you, or when it was being written to the SD card.

I am trying to prepare an SD card for use with a Raspberry Pi and am running into a few problems (caused by my lack of knowledge). I have partitioned the card with an initial DOS partition that has the necessary files needed to boot the Pi, plus the RISC OS image.

It’s actually quite tricky to satisfy all the constraints of various parts of a bootable SD card, and the issues are different for Raspberry Pi and the OMAP machines (beagleboard etc). It’s not just RISC OS, either, some of the bootloaders have specific requirements. You would have a bit more flexibility in how you configure your SD card if you have a CMOS widget but these are not (yet?) available for Raspberry Pi, so you will also need to use a format that works with software CMOS emulation too.

This complexity is one of the reasons why we’re moving towards providing complete ready-to-go disc images. Chris Hall’s disc image is based on this empty disc image, but this contains no useful data at all, not even the Raspberry Pi bootloaders, so I must emphasise that this is only suitable for experienced RISC OS users like John who want to start from the “bare metal”. At the moment, this disc image is a one-off – there are no current partitioning tools on any OS which will create similar images of differing sizes, for example. I am working on writing one at the moment.

If you haven’t already spotted it, a pretty minimal (file level) disc image is created by our autobuilder, and is available as a self-extracting archive here

On xM both test-ROMs work. I Test a copy from the Pandora-boot-card. Anyway…

One test more in the lunch break. ;-)
No drivenumbers. I can’t configure the second (right) card to boot direct under RISC OS. Configure SDFSdrive 1 and save the new CMOS go back to SCSIFS after restart. I insert a !Boot in the Pandora FAT-Card (left slot). It only *Run the !Boot from the ADFS Card in the right slot and configure SDFSDrive 0… That works fine. No card changes are necessary. Both cards are read and writable.
Very good work.

And in the evenning I test this on the new Pandora ;-)

May be the bloody Thumbs helps ;-)

The ROM is not rigth working on the new Pandora. It looks like a display problem. The LEDs flicker just like when the old Pandora boot. But nothing is displayed. The screen remains blank after the start of the loaded ROM. The ROM from 18.07. is still working.

P.S.: I have checked the Modullist this mornig. OMAPVideo and Bootcommand has changed.
Then I have insert a *spool command in Predesk and save the results to the second (right) SDcard. All Predeskcommands without errors. SDFS works fine but nothing is displayed on the screen from the new Pandora. The ext. videocable are not aviable. I have the Plug but not enougth time to make a cable. May be ext. video out work.

Question:
Notaz wrote…

MMC1 supports 3V natively (by OMAP, BIAS control), same as beagleboard
MMC2 is connected to a transceiver chip that translates between 1.8V

SDIOSlots give 3V for both.
These may result in problems or is it just a “write error”, or has it nothing to do with it?

SDFS works fine on the old Pandora, no videoout (intern and extern) on the new Pandora. No longtime tests on this.

That is correct. The reason for this is that *SDIOSlots lists the voltage on the SD card side of the level shifter (if there is one). SDIODriver needs to know about the presence of a level shifter, because one of the first things it does when initialising a card is to tell it which voltage it is operating at. Most users won’t care that there is actually some 1.8V signalling on the board between the OMAP and the level shifter; it is more likely that they are interested in what voltage the card is operating at (some cards are dual-voltage).

I’m afraid I can’t help you with the video problem. I wonder how Jeffrey’s order is coming along?