SD Card Filer

Some information about pandora:

• left slot is connected to MMC1, right slot to MMC2, wifi to MMC3 on OMAP, all 4-bit
• the cards are connected to VMMC1 (left slot) and VMMC2 (right slot) supplies of tps65950 (which is low volume version of twl4030)
• MMC1 supports 3V natively (by OMAP, BIAS control), same as beagleboard
• MMC2 is connected to a transceiver chip that translates between 1.8V for OMAP and card voltage, it’s “transparent” and does not need to be programmed by software (only have to set VMMC2 supply correctly; note that voltage bits are different from VMMC1)
• MMC2 has to loop clock back from the transceiver, so MMCSDIO2ADPCLKISEL bit must be cleared in CONTROL_DEVCONF1

Thank you notaz, that is very useful information. In particular, I hadn’t noticed the MMCSDIO2ADPCLKISEL bit. I have made that change so that Raik can test it.

Can you think of a reason why the TPS65950 GPIO pins (SD card detect) do not work? I am polling bits 0 and 1 of GPIODATAIN1, but Raik says that they always appear as card inserted (bits = 0). The exact same code works for the beagleboard!

I can not see any changes. May be in the tomorrow ROM.
A further Information:
If I eject the card and reinsert, for RISC OS the card is empty but your tool will works correct and see the reinsert card.

I have the 1GB card formated with two partition (first adfs, second fat) and *configure filesystem sdfs and save the cmos… It works fine.
Many thanks.

About the GPIOs, can’t think of anything, they should just work..
Except something messing up GPIODATADIR1 perhaps (should be 0).

Could it be the pull-ups? At the moment, the HAL only configures the TPS GPIO pull-ups if it’s running on a BeagleBoard/BB-xM (see GPIO_Init). If the Pandora version of u-boot isn’t configuring them for us, then that could be causing problems.

The good news at first. With the yesterday ROM more cards are readable.
Dismount 16GB cart give “File to big”.
The second Partition-card is unstable. After use any time directory is broken and the adfs-partition not work any longer :-( I use <25% from space (Fat and adfs).
I have change the pandora-bootmenu (New point). I load the cmos and riscos from ubifs to the adresses in boot.scr. No error-messages all things done. Go with the startadress give a “Starting applikatiom at…” but then … nothing. What is my “think-error”? What makes boot.scr more ore better?

Cards of 4GB or more don’t work properly unless you reformat them using !HForm (and if you do that, you won’t be able to read them on Windows or Mac OS or older versions of Linux). That is a known problem, and is also true for all other RISC OS machines at the moment.

Does it detect when a card is removed yet? Unless RISC OS sees the “card detect” change from “yes” to “no” and back again, it won’t know that it has to use the start-up procedure when you insert a new card.

Perhaps you can use this BASIC program to read some registers from TPS65950?

PRINT"(R)ead or (W)rite? ";
read=GET-ASC("W")
VDUread+ASC("W"),10,13
INPUT"I2C address? "addr$:addr=EVAL(addr$)
INPUT"Register? "reg$:reg=EVAL(reg$)
IF read ELSE INPUT"Value? "value$:value=EVAL(value$)
DIM data 2
DIM trans 24
IF read THEN
data?0 = reg
trans!0 = addr<<1
trans!4 = data
trans!8 = 1
trans!12 = (addr<<1) OR 1
trans!16 = data+1
trans!20 = 1
SYS"OS_IICOp",trans,2
PRINT"Value: ";data?1;" or &";STR$~data?1
ELSE
data?0 = reg
data?1 = value
trans!0 = addr<<1
trans!4 = data
trans!8 = 2
SYS"OS_IICOp",trans,1
ENDIF

To read GPIODATADIR1, use “I2C address” = “&49”, “Register” = “&9B”
To read GPIOPUPDCTR1, use “I2C address” = “&49”, “Register” = “&AB”

(“&” is the way we indicate hexadecimal numbers in RISC OS).

If you want to investigate more registers yourself, or try different values, they are documented in the TPS65950 technical reference manual (search Google for “swcu050g.pdf”).

Sorry, I was a little surprised that my 16GB Pandora-Media-Card is working, so I forgot the 4GB limitation.
With a 16GB ADFS-card I have a other problem. After new start it works, after dismount and reinsert the card/device is empty. Other cards (from 1 to 4GB, 8GB is gone) I can dismount or change without problems.
If the card is usable the “card detection” works fine for both slots. Only the left is displayed and usable.
If I change the card from FAT to ADFS after RISC OS is loading and before sdfs is initialised, the system run only from SDFS. If I change to late, the CLI is displayed (no waiting for bootdevice) and I need a ext. keyboard because pandorakey (also a I2C-module) is in predesk.
I will test your Basic program later. I think if I at home.
The Pandora-bootmenu surprised me a little. If I load the cmos and riscos via fatload it works, if I load via ubifsload, the messages on the screen are the same but after “Starting applikation…” and blank screen it do nothing.
Many thanks.

I’m a little confused. Today the card detect not work.
Yesterday I test from a stick boot system, today from a sdfs boot system.
I will test more in the next time.

Many thanks.

I’ve managed to get the second MMC slot working on the “Zippy” expansion card for my beagleboard. In many ways this is similar to the Pandora’s second MMC slot, so I have made the same changes to the Pandora driver. Let’s hope this works for you!

Sorry, I see no changes in the today ROM. Only one SDFS drive displayed. I boot from sdfs and scsi with the old cmos and a new one for both with changed the scsidevice.
The card detect are not stable. I have tested more cards at home. 1 or 2GB works better then 4,8,16GB with fat or adfs.
If I start with no car it will be displayed with no and if I insert it changed to yes. If I dismount and eject may be it changed to no but most only the writeprotect is changed to yes.
1 or 2GB cards I can dismount and eject and reinsert with no problems, 4GB or bigger the drive is empty after eject.
May be I make a mistake. Any Ideas?
Boot from sdfs with cardchanging works fine.
Many thanks.

I’m many more surprised and confused. In holiday I have all the stuff tested with the new Pandora rebirth edition. In the last hour I used my old Pandora from Batch1. The same firmware and SD cards.
Only one SDSF device are displayed but your tool works pefrect on both slots. No problems with card eject and reinsert, write protect, card detect are working fine. I don’t no what the problem is on the new Pandora. I will take this question to notaz. May be the problems are gone if the new firmware is ready for the Pandora.
Many thanks.

P.S.: After this I see the new final firmware is ready. I will download and upgrade the Pandoras. I think tomorrow it gives the new results.

New firmware on both Pandoras, the same problems. Old Pandora one Icon but the tool and the rest works fine, new Pandora the tool works most not right and the other problems are the same :-(

Raik, I’m sorry about the trouble you’re having. I really don’t understand why it is only showing 1 icon – I know it can do 2 icons because it works with my Beagleboard+Zippy.

Do *SDIOSlots and *SDIODevices print more than one line?

No, no, no thats wrong. I have to thank you. No reason for you to say sorry.
SDIOSlots and SDIODevices print only the one line from the left slot.
The first Pandora sdfs has two icons. I will test this on the old Pandora this evening.

It would be much easier if I had a Pandora to use to investigate this. Perhaps it makes sense to wait until Jeffrey gets his, if Jeffrey doesn’t mind helping.

I think there should be 2 icons, even if card detect is wrong or something else at the electrical level is wrong. It could be one of these:

1) the HAL is not detecting that you have a Pandora, perhaps it thinks it is running on a Beagleboard. Try this:

SYS"OS_Hardware",&403,,,,,,,,4 TO ,,gpio%:PRINT gpio%!&40

This will print 0 for Beagleboard, 1 for DevKit8000, 2 for IGEPv2, 3 for Pandora.

2) I may have introduced a bug when I tried to fix it so that the SD controllers are discovered in the correct order. I think this is unlikely, because it works correctly with my Zippy. However, to be sure, please try this version of my first test program again (in two places, a 4 is replaced by a 5):

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%,,,,,,,5 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%,,,,,,,5 TO ,h%,d%
ENDWHILE

Ok, this are the results:

1. The first line:

Output: -67088460

2. Changed tool

Slot 37, 38, 39 yes, no

The same output on both Pandoras…

But
new: tool not working …
old: tool is working (changes yes and no on card detect and write protect)

I hope this helps… I’am very confused :-(

Many thanks.

A short Test with the old Pandora and the 0307_ROM:

First line: -67088576

Card detect works with the old tool and the old slot numbers…
The changed tool give “Bad hardware reason code!”

sdiodevices and sdioslots print only one line

P.S.: The first line on BeaglexM give 0. I test this from the Pandora SD.
But some strange things happen on the Pandore after next boot. The screen settings on my SDFS card have been automatic changed from Pandora 800×480 to AKF60 800×600, !+Resources give “abort on data transfer” via sdfs in Predesk, via scsi boot it works. Delete this and take the old Pandora MDF configure it works via SDFS…

Good night.

My mistake with the first test – it shouldn’t print 3. But the fact that it didn’t print 0, 1 or 2 means it probably has correctly identified the Pandora.

The fact that it prints “37, 38, 39” means that the HAL is reporting all 3 SD controllers, even using the new call that I added to the kernel. The problem is probably somewhere else.

Can you try this:

SYS"SDIO_Enumerate" TO ,s%,id%
WHILE s%<>0
PRINT~id%
SYS"SDIO_Enumerate",0,s% TO ,s%,id%
ENDWHILE

I expect it to print

    0
  100
10200

If it doesn’t, then try

*RMReInit SDIODriver

Perhaps it makes sense to wait until Jeffrey gets his, if Jeffrey doesn’t mind helping.

I’m happy to help. I just have to wait for my Pandora first :(

@Ben
It print

0
10100

before and after rmreinit.
I only test the yesterday ROM on the old Pandora.

@Jeffrey

What goes wrong with your order?
On openpandora.org I have read “can be bought from stock!”.
Yesterday I see the shop adresses and the uk owner are changed.

I think I might have worked out why the Pandora’s SD icon vanished – an unintended side-effect of other changes affected the value of an uninitialised variable (it’s easy for this to happen when you’re writing assembly language!)

I still don’t know why the WiFi chip isn’t responding. It may be that the chip pin multiplex options are set wrong, or it might be a power problem. However, since we have no driver for the WiFi chip, I don’t think this is an urgent problem.

@Jeffrey

What goes wrong with your order?
On openpandora.org I have read “can be bought from stock!”.
Yesterday I see the shop adresses and the uk owner are changed.

I made the mistake of ordering in 2010, so have been stuck in preorder queue hell since then. From looking at the upgrade queue positions people have posted to the forums I know that there’s no more than twelve people infront of me, so I’m currently assuming that my Pandora will be in the next batch that Craig receives from Ed…

@Ben
In 1995 I wrote any little progamms in Basic and assembler on my A5000 for study but later and today I have not enough time. I don’t understand my own old code :-( but I understand the side effect problems ;-)
WiFi with WPA would be very nice …
The response-problem may be a reason of the “no power management” under RISC OS. With the new firmware all this is disabled.

@Jeffrey
My first Pandora is from Craig. Strange, I thought “from stock = ab Lager” means it is to buy now.
I keep my fingers crossed.