SD Card Filer

That surprises me a little. All plans and sources of Pandora are free. What is needed? I’ll send a link or whatever.
The source code is in Pandora git: http://git.openpandora.org/cgi-bin/gitweb.cgi
Help this: http://www.openpandora.org/downloads/PANDORA_Hackers_manual_v101.pdf
I would try my dangerous way ;-)

anybody had a card not work at all yet

I’ve got an old 2GB ‘Zynet’ card that triggers a ‘disk error’ when trying to access it from RISC OS on the RPi. Both Windows and Linux seem happy to read and write from it tho…

Most of my other SD cards work okay on small files, but tend to freeze when reading/writing large files (10MB+)

Raik: I see the Pandora has 2 SD cards and an SDIO Wi-Fi chip too, interesting. The “Hackers Manual” has almost enough information, but not quite enough. How many DAT pins are connected for MMC1, MMC2 and MMC3? Are the Card Detect switches in the two SD cards slots connected, and what are they connected to? Is the WiFi chip the same one as is used in the IGEPv2?

Just a note to say to anyone listing SD cards which are troublesome (or not) on the Raspberry Pi, it might be useful if you list the output of *SDIODevices. This reveals that many cards are actually just rebranded versions of other ones.

Ben: The questions I can not answer immediately, of course. I will try the information in the coming week to get.
BBFlash recognizes that there are two cards and the first card that can also be write to. No difference to the Beagleboard.

I’ve just noticed that the “Hackers Manual” shows Card Detect lines for both SD slots connected to the “Triton 2”, which I think must be the TWL4030 or TPS65950 (not sure which). Looking at the photos of the board, the connectors look like they both have 4 DAT lines connected. So that just leaves the question of how the SDIO WiFi chip is connected.

It’s a bit unusual that the closest thing to a schematic for the Pandora is hand-drawn on a sheet of A4 lined paper!

Uwe Kall and I have also been amused us about it;-)

Wireless could be wl1251, I think. Have you found nothing in the Source link?

If I have to try something. It runs the ROM from 12.06. on my Pandora.

Ben: TPS65950 is right. Watch here
http://pandorawiki.org/Hardware_documentation

Is it possible for you to compile a ROM or what ever, that lets me try the SDFS on Pandora?

Thank you for your interest

I’ve had a go at Pandora support for you – a ROM image that includes it should be uploaded to the website when the autobuilder next runs (probably overnight).

I haven’t been able to test this support, as I don’t have access to a Pandora myself. Because only simplified schematics are available, it’s possible that I have got the polarity of many things the wrong way round, so please check that:
1) the LEDs are normally off and only turn on when you are using the card
2) the write protect switch works in the correct position (when the tab is slid down)
3) it can detect when either slot is empty, and that it can read a card when you insert one into an empty slot without needing a power cycle

It will also be the first time that SDFS has been tried with more than one drive available, so you may find additional bugs there. I did actually get hold of a Zippy expansion card for my beagleboard with the intention of testing multiple drive support, but I haven’t written a driver for it yet. Now I see it has been discontinued, so I wonder if there’s any point any more, as the number of RISC OS users with a Zippy board can probably be counted on the fingers of one finger. :)

I am with my family on the baltic sea for two weeks but the Pandora is on my side ;-)
I will look at the next ROMs and test. If the weather ist fine it will take any times longer.
As you see Thomas Milius free !ComCentre works fine with my UMTS-Stick and RISC OS on the Pandora ;-)

Many thanks.

The fist Test…
Its not easy to me to describe this.
The main reader left works, but on the desktop it is sdfs1, the right is sdfs0 and it is empty all the time. Changing the card is detecting on both slots (LED) but both are empty after this.
Read and write at the first bevore change are ok. Also the LED.
Write protect Im not tested. Sorry. At this time the accu is down. Charging only with Linux.
I will test any things later.

Many thanks.

I have found two cards (from ten) that works from the main reader (left). Write protect works ok. Both cards not work with the right reader. I have checked all the cards from Camera, MP3-Player…
No Scandisk (4, 16, 32GB), no HP (8, 16GB), no ADATA (32GB)
Only Kingston 8GB and extr-me-mory 1GB works. Writing speed is very slow.
After dismount and reinsert no cards working.

It is normal on RISC OS for drives on the icon bar to be shown in decreasing number order (when you read left to right). I think you are saying that drive 0 is physically on the left on the board?

It is difficult for me to debug this without a board. Perhaps you can try this BASIC program? I need to know if the results are the wrong way round, or if they don’t change at all when you insert/remove a card or move the write protect switch.

DIM P% 100
[OPT 0
.calldevice
 SWI "XOS_EnterOS"
 MOV lr,pc
 MOV pc,r7
 SWI "XOS_LeaveOS"
 MOV pc,lr
]
h%=0
SYS"OS_Hardware",&501,h%,,,,,,,4 TO ,h%,d%
WHILE h%<>-1
PRINT "Slot ";h%-1
A%=d%:B%=0:H%=d%!&78:cd%=USR(calldevice)
PRINT"  Card detect = ";
IF cd% THEN PRINT"yes" ELSE PRINT"no"
A%=d%:B%=0:H%=d%!&7C:wp%=USR(calldevice)
PRINT"  Write protect = ";
IF wp% THEN PRINT"yes" ELSE PRINT"no"
SYS"OS_Hardware",&501,h%,,,,,,,4 TO ,h%,d%
ENDWHILE

I expect it will be difficult if you are on holiday, but are both slots supplied with 3.0V, or are they at 1.8V?

Do both the SD slots work if you try to use them from the U-Boot console (if you have access to that)?

Many thanks.
Your Programm displayed 3-Slots. 0, 1, 2.
Slot0 and 1 are displayed on the Iconbar, slot 1 and 2 are change the yes/no by moving the protect switch. I dont no what slot 0 is.
Card-boot works only from the left slot. I have no other access yet.

That surprised me, I expected 0 to be MMC1 (a card slot), 1 to be MMC2 (the other card slot) and 2 to be MMC3 (the SDIO WiFi chip).

I’ve just looked at the kernel’s handling of HAL devices (which is what my test program lists, and is what SDIODriver uses to locate the available SD controllers). It seems that devices are listed in the reverse of the order they were registered in, which explains that. I have only myself to blame – I wrote that code, though it was 10 years ago now, and I don’t remember why I did it that way! Perhaps it was so that if you only support one device of a particular class, you only get the most recent one. It’s not what you want for things like SDIODriver, which do support multiple devices – it would mean that the order of SDFS drives would be different depending upon whether an expansion card driver module was loaded before or after SDIODriver.

I can’t quite decide whether to fix that by adding an extra reason code to OS_Hardware which enumerates devices in registration order, or whether to make SDIODriver reverse the order it receives them from the existing reason code.

Raik, to be clear, please can you tell me what both “Card detect” and “Write protect” say, for both slots, and in these three situations:

• no card inserted
• card inserted with protect switch up (off)
• card inserted with protect switch down (on)

You said the left slot works, is that drive :0 or drive :1?

Please can you tell me what you see when you use the commands

*SDIODevices

*SDIOSlots

Hi, to many english for me. I hope I understand. ;-)

Without cards:
Slot0: detect yes writeprotect no
Slot1: detect yes writeprotect yes
Slot2: detect yes writeprotect yes

Unprotect cards:
Slot0: detect yes writeprotect no
Slot1: detect yes writeprotect no
Slot2: detect yes writeprotect no

Protect cards:
Slot0: detect yes writeprotect no
Slot1: detect yes writeprotect yes
Slot2: detect yes writeprotect yes

?????: not working SDFS0 on the iconbar
Left Slot: Slot1 = the working slot SDFS1
Right Slot: Slot2 = not displayed on the iconbar

*SDIODevices
Bus Slt RCA Fun Description Capacity Vendor Product Rev Date

*SDIOSlots
Bus Slt Voltage With Frequenzy

I hope that helps.

Thank you.

Dein Englisch ist viel besser als mein Deutsch :-)

That is very useful, thank you. Write protect seems to be working perfectly on both slots, but card detect is broken. It should say “no” when the cards are not inserted.

Slots are listed in the reverse order of what I expected. I assume the left slot is the one that you use for the card containing U-Boot? We need that to be drive SDFS::0 so that CMOS RAM emulation works.

I expected to see at least the WiFi device in *SDIODevices and *SDIOSlots. I’m not sure why that failed – its power supply is not under software control, and it can’t be removed (it is soldered to the PCB!) That may have to wait until if/when somebody writes the SDIO WiFi driver.

I have made some changes that might help, although I might have been too late for tonight’s autobuild. If tomorrow’s ROM behaves the same, try Saturday’s ROM.

Your German words are perfect. Let’s try it ;-)

Sorry. My mistake. I changed the firmware before I go to holyday. At default with the new powermanagement all ports (usb, bluetooth, wifi) disabled. With the may-rom, I mean, I can direct start riscos by power on… since june I must start Linux and enable the usb host and restart without power off to boot from stick. I take this with additional enable wifi yet.
I don’t no if the problems are from firmware or from riscos. The new powermanagement is inside since january but I changed from beta4 to beta5a in may. I will control this later.
The new output from *spool with usb ans wifi enabled:

*sdiodevices

Bus Slt RCA Fun Description Capacity Vendor Product Rev Date

*sdioslots

Bus Slt Voltage Width Frequency

With omly the second sd it has the same output from yesterday.

My 8GB card is mechanical broken by use the protect switch. I hope I can repair this :-(

Many thanks

The today ROM is changed. Only one sdfs device is displayed. It is the left and it is sdfs0.
With your tool is slot3 the main left and slot2 the second. The first must be wifi(?).
New changes tomorrow?

Many thanks.

I know this is a bit confusing, but we are trying to fix several bugs at the same time!

Does the card detect change to “no” now when you remove the cards?

I am not sure why the second SD card slot does not work. It does not help that I don’t know how Pandora’s power control is configured! It could take us a long time to fix this by trying one new thing per day, so I think it makes more sense if I try to make the second SD slot work on my Zippy board first. If I can get that working, but the Pandora’s second slot still doesn’t work, then we will know that it must be some difference in the power supply.

The card detect no change to no. The same as before. Only the slots are change.
I don’t have information about the power control but the powermanagement has not changed for the cardslots. In Linux the slots are present if a card is inside.
Sorry, I’m only a user. Can you change the “first Pandora code” that the card slots are displayed on the iconbar and not the “wifi” or all 3 sdfs devices – the most cardreader do so ;-)
I will take any questions to Notaz, the main programmer of the firmware. I hope he has a answer. Tell me witch things are interested in.
Many thanks.

Children sleeping after lunch…
A little mistake …
Slot2 is the main left, slot1 second, slot0 wifi

I have just tried an SD card in my Devkit8000 using riscos 5.19 downloaded 5 july 2012, and would like to report that it reads ok but reports read only on any attempt to write to it.

The card is not write prot and will write on a Pandaboard.

I started risc os like this

OMAP3 DevKit8000 # mmcinit;fatload mmc 0 80000000 riscos; go 80000000
reading riscos

2259092 bytes read

1. Starting application at 0×80000000 …
   OMAP3 HAL init
   Board config=BeagleBoard
   HAL_Init
   BB revision GPIOs=00000007
   HAL initialised

I noticed that RISC OS thinks its as Beagleboard. I remember seeing somewhere that there are different start addresses to a force board id but I couldn’t find that again today to see if that made any difference.

Alan

Update:
If I boot it like this
mmcinit;fatload mmc 0 81000000 riscos; go 81000004

Then SDFS does write to the MMC card as expected.
Thanks for the info.

Alan,
Just a passing thought, but if you are experimenting perhaps using the u-boot files at http://http://git.sabayon.org/molecules.git/tree/boot/arm/beagleboard-xm might be useful. IIRC the Devkit is a sort of beagle clone.

note the files are MLO, u-boot.img (not u-boot.bin) and you replace the uEnv.txt they supply with one that contains:
uenvcmd=fatload mmc ${mmcdev} ${loadaddr} riscos;go ${loadaddr}

If the info is correct the file combination you then have should work on any revision of beagle or clone.

Certainly works fine on a beagle-xm and the boot seems a bit faster than my original u-boot.

OMAP3 DevKit8000 # mmcinit;fatload mmc 0 80000000 riscos; go 80000000

It should be mmcinit;fatload mmc 0 81000000 riscos; go 81000004