This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#7134 - Sansa: external sd-card support
Attached to Project:
Rockbox
Opened by Toni (ahellmann) - Tuesday, 08 May 2007, 23:06 GMT+2
Last edited by Michael Sevakis (MikeS) - Saturday, 30 June 2007, 04:25 GMT+2
Opened by Toni (ahellmann) - Tuesday, 08 May 2007, 23:06 GMT+2
Last edited by Michael Sevakis (MikeS) - Saturday, 30 June 2007, 04:25 GMT+2
|
DetailsThis patch adds sd-card support to the software. It still has some freeze issues during hotswap. A 15sec press of the power button is your friend here. Please give feedback, wether the patched software basically runs with your sd-card.
Tag-/DirCache had to be disabled, because that part is not completely prepared for multi volume support. You have to update also the codecs and plugins. 
sd-card.patch
(10.8 KiB)
rockbox-daily-20070511/firmware/export/config-e200.h | 4 rockbox-daily-20070511/firmware/export/config.h | 2 rockbox-daily-20070511/firmware/SOURCES | 2 rockbox-daily-20070511/firmware/target/arm/sandisk/sansa-e200/ata-e200.c | 238 +++++++++- 4 files changed, 224 insertions(+), 22 deletions(-) |
This task depends upon
Closed by Michael Sevakis (MikeS)
Saturday, 30 June 2007, 04:25 GMT+2
Reason for closing: Accepted
Additional comments about closing: Forgot to mention in my commit message that this disables dircache which is a nice bonus given that it doesn't speed anything up. Database seems to work fine.
Saturday, 30 June 2007, 04:25 GMT+2
Reason for closing: Accepted
Additional comments about closing: Forgot to mention in my commit message that this disables dircache which is a nice bonus given that it doesn't speed anything up. Database seems to work fine.
Congrats, Toni... looks good to me. Thanks a million!
great work again toni, keep it up!
and i think it wouldn't a big deal to commit this patch to svn, because you only can have problems if you have a microSD card inserted, right?
great work :)
Having a quick look at the patch (after actually applying it and being excited because it works) I'm fairly sure the HAVE_MMC define is used badly throughout the code, Accordin to ammicon it is used for targets with slow disks and no spinup time and low ram, which the sansa doesnt fall into, so i'm hoping that my attached version of your patch fixes your crashes which could have been because of that.
This doesnt fix tagcache or dircache at all, but it does change the <MMC> to <mSD> :) (also, if this is all good, the mmc_* function names will need changing)
<SDCARD1> is just as good as <mSD1>, it would be even better if we could use the dos prtitio name there, but without some extra work I dont tinhk thats doable.
yes, I tried your patch. But without luck. Still some freezes and detection time around 3sec (hama 512MB). This is too much compared to my first trials. Either I partly damaged the card/slot or the 'old' bootloader causes this detection time increase. Is the detection time on yours also ~3sec? Do you use an updated bootloader?
Im using the latest bootloader and detectio times are <1s... so maybe it your card/slot?
we had a very quick talk in irc abot this and its OK to commit without fixing dircache/ramDB but this isnt going to get the last targe with external cards, so both shuold be fixed up in the fllness of time to work properly :)
slightly OT, but I've been playing around with giving each card a "unique" id (really just incrementing the count of known cards) which works (although badly...), but the hope is that if we can get this workin nicely, hopefully we can get database to hide files which are not on the currently inserted card.
Also incuded in this patch is the .rb_cardid detection I mntiond above (probably not wanted just yet, but dont have tim to strip it from the patch), and lastly, I have fixed up the mmc stuff so we now use hotswap instead of MMC and integrationg into target tree....
I don't know exactly (no >2GB card here), but it seems, the external card can be handled in the same way as internal ones; switching the banks should do the job hopefully.
jdgordon:
I tried your latest patch against current svn: After adding the missing hotswap-target.h (adding prototypes), I get constant freezing during booting. Removing the patch solves this issue. Do I have to destrap something?
hotswap.diff
what freezing are yo having? does it unfreeze after 5s or its a full lockup? (come on irc...)
hotswap.diff
Bjorn, why arnt I getting notification emails?
patching file apps/settings_list.c
Hunk #1 FAILED at 1188.
1 out of 1 hunk FAILED -- saving rejects to file apps/settings_list.c.rej
Charles
- resynched with svn
- readds sdcard debug info
- the ideas from previous patches included
- panics on sdcard driver timeout detection (helps supporting)
- uses 'card' instead of 'hotswap' prefixes
- major rework of the sdcard driver (performance, simplification, minor bugfixes)
Why rename the hotswap prefixes to card? I used hotswap so it would be blatantly obvious that it relates to the HAVE_HOTSWAP define and hotswap files. card I tihnk could be confusing later on.
in the patch there is both SYS_CARD_EXTRACTED and SYS_HOTSWAP_EXTRACTED....
hmmm, seems it likes panincing with error 14 if I start it with a msd inserted.
also, if all the cards (mSD and MMC) have the serial# then we can get rid of the .rb_cardid stuff in tree.c and just use that.
edit: bugger, swapped cards again, and crashed with no panic.
I also get this error on the external card after many successful readings. So it is not special to my suspicous card. :-(
Increasing the timeout value for the 'wait for FIFO full' condition did not solve the issue here. OK, will think of your
other comments.
The patching was ok? Did you do a 'make clean' + '../tools/configure'?
> Not sure what a "make clean" is,
Make clean clears out all the compile bits, but leave your configuration as it is.
> but I patched it to brand-new, checked-out SVN. Yes, it patched, but it failed in the build.
If you don't tell us what errors you are getting, no one can help you.
Charles
OK, just did an update. You need to hand patch the reject for misc.c.
Charles
I got that bit set after executing the STATUS_REG command. This error appears ALWAYS when reading special
sectors on the external card (address here: 0x3068000). But reading the data via a PC connection gives
the correct result. So this error seems to be recoverable. Probably by changing the timings? Until that
issue is solved, I hesitate to commit this patch. But I currenly have no idea, how to solve this issue.
I attached the .rej file that I get when I apply the hotswap patch.
I also modified the hotswap1.patch so it doesn't ask for the location of the files to be patched
Do you mean songs on a MicroSD card (I don't have one so I can't test it out). However, bookmarking works fine for me with the hotswap1.patch applied.
Charles
The only error I get when I apply the patch is:
patching file /test/apps/misc.c
Hunk #1 FAILED at 47.
Hunk #2 succeeded at 816 (offset 1 line).
1 out of 2 hunks FAILED -- saving rejects to file /test/apps/misc.c.rej
You should really learn about patch levels (-p option) in the patch program. You are bound to encounter problems like this in the future when applying patches.
> No just in general through out the whole player.
Strange try my resynced patch and see if bookmarks are working for you.
Charles
Now the Bookmarks work.
patching file firmware/target/arm/sandisk/sansa-e200/ata-e200.c
Hunk #3 FAILED at 67.
Hunk #4 succeeded at 243 (offset 1 line).
Hunk #5 succeeded at 282 (offset 1 line).
Hunk #6 succeeded at 298 (offset 1 line).
Hunk #7 succeeded at 366 with fuzz 1 (offset -1 lines).
Hunk #8 FAILED at 417.
Hunk #9 FAILED at 434.
Hunk #10 FAILED at 499.
Hunk #11 succeeded at 580 (offset -1 lines).
Hunk #12 succeeded at 650 (offset -1 lines).
4 out of 12 hunks FAILED -- saving rejects to file firmware/target/arm/sandisk/s
ansa-e200/ata-e200.c.rej
edit: forgot hotswap-target.h
edit: yes, i just commited a quick one which breaks 1 line in this patch... you shuold b able to work it out yourself though :D
Toni, had any luck crashing it lately? The only panic I saw today was when the interrupts were being used wrongly :)
also, removed the card id stuff... it can be added later if we end up using it, but I tihnk the serial number for the card would be better
and i found a reproducable bug:
enter the file menu
move to some dir on the SD card
exit to main menu
reenter to the files menu
exit again to the main menu
and then if i try to enter the files menu again, it seems i'm stuck in an infinite loop
Rene's bug is very producable and im slightly suspecting this is a bug in the FAT/dir driver.. unless of course it doesnt happen on the ondio...
I have fixed the bootloader and sim to both compile, ideally, I'd like to be able to boot rockbox.mi4 off the sd card later, but for now the only chage was to get it to compile.
now onto new bugs after my hacking.
I had a feeling that we were crashign it because card_info[1].initialized = false; wasnt being set before the hotswap_inserted broadcast, so I moved that to above the if (!current_status) check in microsd_int() so it always happens. This shouldnt have caused any problems but it possibly has :(
Booting with a mSD card inserted gives interesting bugs (with svn bootloader). Either it will load rockbox correctly and panic with error 14 (btw, I saw PANIC: 1 which was odd... but only once.), or it will load rockbox, but it wont mount the internal disk! going into files shos the contents of the mSD as the / AS WELL as showing <microSD1> and <microSD2> which both are the same (the 2nd one is probably because I increas NUM_VOLUMES to 8 instead of 2 which I thought may be causing problems also.)
other than that, I have nothing to report... hopefully Toni has got somewhere?
Through painfull debugging to the lcd I have narrowed the crash/loop down to firmware/drivers/fat.c..
somehwere between
if ( numsec > (long)fat_bpb->bpb_secperclus || !cluster ) {
long oldcluster = cluster;
if (write)
cluster = next_write_cluster(file, cluster, §or);
else {
cluster = get_next_cluster(IF_MV2(fat_bpb,) cluster);
sector = cluster2sec(IF_MV2(fat_bpb,) cluster);
}
in fat_readwrite()..
I give up for now...
does anyone know if this bug is because of something I did? or this has been there from the start but never reported before?
Recording relies on a yielding driver simply because yielding in recording itself when flushing causes problems for HD-based models since the ATA driver yields almost too much already.
Was changing them requied for recording to work? doing a recording which is greater than 32mb shold be enough to find out if its broken right?
edit: ok, getting annoying... changing the spinlocks to mutexes with the patch from last night still causes problems. is the ata driver really that finiky?
edit2: fuck! reverted to before the rec commit, merged the patch from that time, fixed it up, changed spinlock to mutex, updated then to current svn and stll crashing going root menu -> sdcard :'(
Things should run in a more timely manner with spinlocks and I'd recommend staying with it unless you want priority inversion problems in the driver. It will suffer the same as the ata driver on HD targets and the I2C on pp targets (which once made the player unresponsive during buffering) if it doesn't use them...yielding or not. OT: Really, the need for them is a scheduler bug IMO.
BTW: Is there any contention that can result from attemping access of both simultaneously? I'm just thinking of stuff randomly atm though.
I'm sure it could be posible that both disks could be trying to be accessed at the same time, but in both read and write the current disk is checked against and will initialise the mSD card if the hard diskwas the last accesed, and both use the same locks, so that shuoldnt cause problems...
edit: small update.. it seems the merge screwed the spilock initing... mutex_init() was being called at ata_init() AND spinlock_init() was beign called at the end of sd_init_device(), however, removing the one in sd_init_device() doesnt fix the problem yet (that is only called when the the caller has the lock so dont try to unlock it again...) It still freezes up somewhere
the major problem now is that it will crash/infinite loop very reliably if we try being smart at all and not re-initializing the disk before a read/write. so its a very noticable slow down on boot (an extra second or 2 maybe), not noticable anywhere else though. Havnt tried recording though.
Mike: I have to use mutex's through the code... using spinlocks will crash very reliably if you start music from the sd card, then go back to the root menu while its buffering (may actually crash before that, but doing that twice was enough to prove it didnt work for me.)
hmm... that was odd... I'm listening to music on the sd card atm, and it just changed tracks to a different folder (on the sd card) in the middle of a song... probbaly unrelated though becuase it didnt crash at all....?
please test the patch and let me know how you go :)
The need to reinit, use regular mutexes (any lock mechanism should at least function) and other problems I see you're having shows that it needs a real going over. I've no guess at what it is atm. :\
The only context switch in the ata code now is the priority-yield right? could that be causing a deadlock?
Im going to play around with the old versions of the patch (before the ata-e200 rework toni did) and see if it works better.
Maybe the lock isn't entered at the right time and should happen sooner?
The radio driver is doing outl(inl(0x70000080) | 0x4, 0x70000080) when the radio is started. The sd card driver turns this bit on and off depending on the current volume and I'm guessing the radio driver shouldn't touch it.
Perhaps the message handlers in sd_thread should enter the lock when changing the file system around.
Why is a full init being done every time the current volume is changed? Ex: Even with filtering the init, why do a DEV_RS all the time?
More stuff but I won't run the web browser out of memory listing it all ;)
/me needs to obtain and read the SD card manuals now
I can't say I'm at all happy with the robustness of rockbox in in general in handling errors from a precipitously extracted SD card. </gripe>
panic, error SDCard: 1
The problems I reported were actually with sansa-sd-hotswap3.patch. When I recompiled using fresh source and sansa-sd-hotswap4.patch, they seem to have been rectified. I get no freezeups at all. In fact, pulling the card while playing a track seems not to faze it in the slightest; it just keeps playing. I even FFed to near the end of a track from the card and then pulled it out. It moved on to the next one as if the card were still inserted.
It appears that some e250s have two chips on the daughterboard (each 1024 MB) while others have one chip (2048 MB)
I take it that the problems occur with the SD card, but if no SD card is plugged everything is ok with the internal flash?
Could you perhaps post the debug info for your memories (System|Debug|View microSD Info)? All info from each page in a .txt file would be fine. Your info may tell something important about timings.
I have a 4GB model with 2x2048MB so multiple chips in itself aren't the problem but perhaps the 1024MB flashes are slower in some respect?
Personally, I'd be ok with committing this so long as main drive access in not hurt since nothing would be lost over current SVN and it would encourage wider trials. Many would also benefit with being able to use the SD card right off the bat. Work on getting it operational for everyone would of course continue.
You there? Could you please check that the patch doesn't revert to the previous behavior after booting to the original firmware? If it does, there's something else that needs setting up (but I can't imagine what yet) and if it doesn't, perhaps something in the card slot was physically stuck and dislodged after inserting a card?