Beta Testers Needed

Need one more tester for T5, One more for LifeDrive, and Two more for Zire 72.

Do not get excited yet, there are conditions and requirements!

1. You must be old enough and willing to legally sign a nondisclosure agreement (NDA), which will disallow you from distributing the driver to anyone.
   
2. You must reside in the USA(allows the NDA to be easily enforceable)
   
3. You must have the device in question
   
4. You must have SD and SDHC cards and commit to at least some daily use of each
   
5. This is an unpaid position, and there is no compensation of any kind for this, including free copies of this driver
   
6. The beta driver may expire before final is released
   

No exceptions!

If anyone is still interested, email dmitrygr@gmail.com with email subject of "SDHC BETA", in the email include:

• your name
  
• device type
  
• state or province you reside in
  
• cards you plan to test with
  
• any other information that you think would convince me that you'd be a good person to test this
  

To everyone outside of the USA: sorry. I've been burned by too-open betas and piracy too badly to allow any chance of this happening again. Since i am not willing to deal with potential NDA breach in another country, I cannot allow this at this time. Please do not take this personally.

Updates

Thanks to Em, who tested the proposed beta version and gave a few interesting suggestions. They will be implemented and then beta will be given to testers. testers will be contacted soon with a link to the NDA to sign and a fax number to fax it to.

T|T3 will take a bit of time as there is a number of steps inside Winbond that need to happen before I am able to get the needed documentation.

Update

Registration engine has been completely revamped to make it more user friendly - no UI and none of that annoying entering of random numbers. You just install a key file and the driver becomes registered. Trial version will be fully functional for some number of days (specific number not yet decided on), after which it will be speed-limited to about 50 KB/s and read-only. One may, of course, at any point delete it and switch to the original palm driver.

If all goes to plan, beta testing cards will be written and prepared for shipping tomorrow. Beta testers will also be selected from the pool pf applicants and sent the NDA to sign. When a tester signs the NDA, I will ship out the read-only SD card with the beta driver to him/her. The tester will then run it to obtain the device ID, which will be sent to me, in return a key file will be sent to the tester to enable unlimited operation.

Assuming no major bugs are found during the beta phase, it will run for a week or two, after which sales to the general public will begin.

I will continue perusing Zodiac and T|T3 support, since it seems those hold the majority of user interest among all the devices not currently supported by this driver.

Zodiac driver is written and works, but the DRM in the OS prevents its reliable operation. Turning the DRM completely off is currently not considered a good solution, and a better one is being researched.

T|T3 driver work will begin once I get the detailed specs for the T|T3's SD controller chip from Winbond (hopefully soon). Depending on the complexity of this interface and the intricacies of working with this chip, support for T|T3 could come in a week or in a month.

All other devices can be supported, but I will need a large-ish group of users of such devices to pledge to buy the driver before I set off working on support for that device.

T|T3 #7

T|T3 progress:

I heard from KC So. The spec will cost some money, but it is doable. You T|T3 owners better buy this driver enough to recoup this cost! You hear me??

Beta

Well, i will spend this weekend getting beta ready and sent out.

Beta includes users of TX, T|T5, LifeDrive, and Zire 72.
Beta testers will be notified around Sunday, if all goes well.

T|T3 #6 and zodiac #3

Zodiac drm is getting in the way a lot. zodiac development of the driver is suspended till i have time to waste

as for t3 - kc so from winbond has not gotten back to me yet. will call again tomorrow.

For Zodiac developers

If you want to diagnose Zodiac fatal exceptions, or crashes in your app, this post is for you. The slighty-informative fatal exception box can be expanded a LOT. It is simple. First, I will assume you're programming in ARM. Then do this:

void* oldState = installExpansion(&__call_expander_func);
....
....
crashing code
....
....
installExpansion(oldState);


this will install expanded error handler function myExpander(). This function is for you to write, and has prototype void myExpander(ExceptionFrame* exc);
The usefullines is in the wealth of information that this function gets - it gets the full exception frame, including all registers, address that caused the error, etc... This can be very useful. See code lsiting below for more info

Additionally you'll need the following code listing:


typedef struct{

UInt32 zodFaultCategory;
UInt32 saved_user_R0;
UInt32 saved_user_R1;
UInt32 saved_user_R2;
UInt32 saved_user_R3;
UInt32 saved_user_R4;
UInt32 saved_user_R5;
UInt32 saved_user_R6;
UInt32 saved_user_R7;
UInt32 saved_user_R8;
UInt32 saved_user_R9;
UInt32 saved_user_R10;
UInt32 saved_user_R11;
UInt32 saved_user_R12;
UInt32 saved_user_SP;
UInt32 saved_user_LR;
UInt32 saved_user_CPSR;
UInt32 saved_svc_SP;
UInt32 saved_svc_LR;
UInt32 saved_svr_SPSR;
UInt32 saved_art_SP;
UInt32 saved_abt_LR;
UInt32 saved_abt_SPSR;
UInt32 saved_und_SP;
UInt32 saved_und_LR;
UInt32 saved_und_SPSR;
UInt32 saved_irq_SP;
UInt32 saved_irq_LR;
UInt32 saved_irq_SPSR;
UInt32 saved_fiq_R8;
UInt32 saved_fiq_R9;
UInt32 saved_fiq_R10;
UInt32 saved_fiq_R11;
UInt32 saved_fiq_R12;
UInt32 saved_fiq_SP;
UInt32 saved_fiq_LR;
UInt32 saved_fiq_SPSR;
UInt32 faultStatus;
UInt32 faultAddress;
UInt32 PC_whe_we_hit_error;
}ExceptionFrame; //for sys FatalAlert, at entry pointed to by R4


asm void* installExpansion(void* func){
LDR R1,[R9,#-12]
LDR R2,[R1,#0x444]
STR R0,[R1,#0x444]
MOV R0,R2
BX LR
}

asm void __call_expander_func(){
MOV R0,R4
B myExpander
}

Zodiac #3

Well, the system is NOT liking the driver. stupid security is hanging the system on next app switch
now working on putting the security system out of its misery...

Zodiac #2

It works!!!

The solution was to just reset the controller after all data operations. This caused the maximum speed of transfers to fall, BUT now it works correctly. :-)

Zodiac

Did a lot of work on Zodiac, rewrote most of Zodiac's SdDAL module. It it is annoying that I can get it to work, but only if I do something that exactly matches the "do not do this" section of the processor's manual. If I do what it says to do, data gets lost. Obviously I will not be releasing code that is wrong, even if it works... Let's hope this is easily resolvable.

volumes over 4GB

Palm's API does not have support for volumes over 4GB. This is a problem. The following is a proposition-letter I sent to a few PalmOS developers, that will hopefully help fix this situation. Comments are welcome.

Hello, As you may already be aware I am writing an SDHC driver for all PalmOS 5 devices, due to be released soon. After that, I will release a FAT32 driver, to fix the horrific performance of palm's driver. This brings into contrast PalmOS's VFS layer's problems in dealing with reporting volume sizes and free sizes over 4GB. I plan to introduce a new API in my driver, and would like to ask you to add support for it in your products. It should be a very painless, and backwards compatible to do so. The api consists of two parts. There is a Feature ('PpFs', 0x3137). If it is present and its value is 1 or greater, the device has the driver and supports the new api. To call it, you need to call the relevant filesystem library's CustomControl function. The creator for the call should be 'PpFs' and the call id should be 0 to get total card space and 1 to get free space. The parameter should be a pointer to a UInt32 where the return value is stored. The return value is not in bytes like palm's api, but in blocks of 512 bytes. Thus a return of 2048 after a call to get free space means that there is 1MB free on the card. Please reply with your opinion on adding support for this.

Speed

About speed of mine vs Palm's driver.
Vertical scale is the same in both graphs.
Test was done with a Sandisk 512MB card, on a Palm TX after a clean hard reset.

Mine:



Palm:

Zire72

now seems to work read/write:)

T|T3 #5

UPDATE: Talked to KC So again. thanks to a user on 1src, who called him and found out some more information. The problem was that Winbond thought my project was open source. I have called them, and assured them otherwise, and KC So said he will try to help me get the spec sheet. Thank you everyone who's helped.

T|T3 #4

A very helpful person at Arrow, a distributor of Winbond's chips spent the last few days trying to help me get this spec sheet. He was unable, due to Winbond ignoring all requests for detailed sheet, but still he did all he could. Thank you very much, Brandon.

Reverse engineering effort will continue.

KC So, Winbond's director of marketing, USA said their support resources are stretched too thin to allow them to email me a single 3MB PDF file with the specs, even if I agree to pay for it, sign an N.D.A., and agree to not contact them with any further questions.

EDIT: talked to them again, things are looking better. See post above this one...


Specifically I need them to give me the non-public specification sheet for W86L488Y. The public spec sheet lists device registers on pages 15-17, but does not list the bits in those registers and what they do - making it useless. The detailed sheet they refuse to help with lists those.

FAQ

Q: What's the largest supported card?
A: I've tested 16GB, and it works, anything larger will too *

Q: Besides this driver what do I need to use big cards
A: On TX and LideDrive - nothing.* On all other devices to use cards 8GB+ you need a FAT32 driver.*

Q: How fast is it?
A: Currently the driver is significantly faster than the stock driver for multi-block writes, but until I release my own FAT32 implementation you're unlikely to see much increase in speed since palm's version of FAT32 rarely uses multi-block writes, for some reason.

*: PalmOS cannot report free or total space of a device over 4GB. This is an architectural and an API limit. I am releasing a hack that would help legacy applications overcome it in at least some way, while at the same time I will release a more modern api and encourage all software developers to use it.

T|T3 #3

Still nothing from Winbond(I'll call KC So again tomorrow), but I made some progress on my own. Still nothing too exciting, but I expect to get command-response communication working soon.

T|T3 #2

Wow, i feel sort of stupid...

I went about reverse engineering how this chip works, and wasted lots of time on it. Today just for kicks I called up Winbond - the maker of the T3's SD chip and asked for the specs. They said call a distributor. I called a distributor of theirs, who took down my information and said they will contact me when you get me the specification! Hopefully this will go well, and save me countless more hours of reverse-engineering how this thing works...


EDIT: I called winbond again, and this time spoke with KC So, Marketing Director. This conversation differed from what I heard before, but he said he will see if he can get me the specification, so hopefully this will help.

T|T3

T3's SD controller is as good as undocumented since no information on it can be obtained easily.

Most information on the 'net about is either useless(the public spec. sheet) or wrong(the palm Linux project driver). So I went on to figure out how it works. The original driver only uses part of the functionality, but I am determined to get it to work completely. So far I mostly figured out the command/response related registers, and the response FIFO. The data FIFO is still not working too well, but it will soon.

The cool part about this chip is that the FIFO shows how many bytes are in it, unlike other CPUs, where you just get a full/not full bit.

Bug A

Bug A is fixed :)

Update

Looked long and hard at bug B, as a result more MMCs now work, 4-bit MMC mode now works, and multi-block MMC writes now work. Some MMCplus cards still continue to resist...

Bug A solution is becoming clearer...

Devices update

Device	Support level	Notes
TX	Full	Known bugs A and B
Tungsten T5	Full	Known bugs A and B
LifeDrive	Full	Known bugs A and B
Zire 72	Read Only	Known bugs A, B and C
Zodiac	In progress.	Commands work, data transmission not yet. Right slot only.
Tungsten T3	In progress.	Mostly finished mapping out the undocumented SD chip. Driver work to begin soon

Bugs:

Bug	Description	Priority	Cause known/Fix known
A	Inserting/removing card while device is off is not acknowleged	Medium	Yes/Partially UPDATE:FIXED
B	MMC[plus] Cards are readonly	Low	No
C	100% write CRC errors on Zire 72	Medium	Yes/No

Welcome

Welcome to the Palm SDHC project blog. Since there has been a tremendous interest in the project, and I am tired of answering all the questions about the status, this blog is being started. All updates and notes will be posted here. This blog is hereby the authoritative source of all news and latests updates to the project.