I agree that the blocks wouldn't need to be contiguous. They just need to be easy to identify.
If you do a WRLONG to ROM, nothing happens.
I've been working on the ROM code, by the way. I never thought about using it to load the chip over Zigbee, but that would definitely work. Here is the command set:
PROP II MONITOR COMMANDS
------------------------
>[space] 'recalibrate baud
>TB 'byte data (default)
>TW 'word data
>TL 'long data
>[enter] 'view more data
>address 'view data
>address.address 'view data range
>:data data.. 'write more data
>address:data data.. 'write data
>address.address:data data.. 'write data range (fill)
>/ 'search next
>/data data.. 'search data from current
>address/ 'search from address
>address/data data.. 'search data from address
>address.address/ 'search in range
>address.address/data data.. 'search data in range
>address.address>address 'move from range to address
>address.address<address 'move from address to range
>G code parm 'start new cog
>G code parm cog 'start cog
>X cog 'stop cog
>P value 'set config
>M 'show cog usage (8 bits)
>' 'repeat last command (no need for [enter])
Some type of feature needs to be put in ROM to ensure a verified data transfer. Not to be picky, but, if the protocol cannot handle bit errors and detect them then the protocol is weak.
I think a send checksum command was spoke of. I guess that would be good... but, the checksum itself could be corrupted during transfer...
Eh, anyway, I'm mentioning this because the P2 is targeted for professionals. Error handling needs to be present.
post #1127
There is no more RDxxxx reg,#imm, so there's no more direct hub addressing. There is only RDxxxx reg,PTRx[-32..+31]. Since we aren't going to have lots of 'zero-page' memory, I re-purposed the bit that toggled #/PTRx mode and gave PTRx one more bit of offset range (was -16..+15).
Chip: I don't think this is smart. The immediate hub address mode permits quick vector decoding (like I did on the spin interpreter). There are other smart uses of this immediate mode too. Otherwise, I have no preference wither way for ROM being hi or lo. Maybe you could use the second page ($200-$3FF) for the imediate mode on rd/wr to hub?
Please keep it simple. Again, we could load a better monitor just from the base monitor. So it should have CRCC or BCC for protection. Just the basic commands. Be careful this isn't seen as a hobby thing!
SD BOOT
Please reserve me about 150 longs in ROM (I expect it will be less than this) to read some boot sectors (same length as for SPI would be best). Due to my workload others are testing the SD cards for me. My proposal does not care what OS, if any, is on the card. I believe this has the least risk and the best opportunity for future-proofing. It also happens to be the simplest and shortest.
It is just a few simple SD commands and we can read a group of sectors for the initial SD booting. It is already working, and I am looking for what SD cards already have in the MBR (sector 0) on the SD card.
Chip: I don't think this is smart. The immediate hub address mode permits quick vector decoding (like I did on the spin interpreter). There are other smart uses of this immediate mode too. Otherwise, I have no preference wither way for ROM being hi or lo. Maybe you could use the second page ($200-$3FF) for the imediate mode on rd/wr to hub?
come on, Cluso99. Why the second guessing? you set the base pointer and then can get immediate access to 64 different longs. This is way better than what is going on now on the P1, which for every variable you want to pull in, you have to keep adding 4 along with the RDLONG.
Maybe not really a benefit, but if we're talking about objects, it gets rid of the notion of a precious area of fixed memory at the very beginning of HUB RAM that greedy objects are going to say that they need or else won't work.
One caveat I see about the beginning area being ROM, is that let's say we have the ability to still create a RAM or EEPROM file, is the area pertaining to the RAM still just going to be filled with 0's, so that there's a 1:1 correlation between the HUB ram addresses and the bytes in the file? 128 KB file loaded to 128 KB hub RAM instead of something weird like 126 KB file loaded into hub ram starting at address $800 ?
---
Separate idea:
I'm wondering for future designs, if the Cog RAM in Cog 0 could have that extra transistor to be able to be "reset" to the boot code. That way it doesn't live in the hub area at all. This was the next logical progression.
There was requests not to make the change the first time Chip suggested it. I believe one request came from Cluso. So, not second guessing at all.
you set the base pointer and then can get immediate access to 64 different longs. This is way better than what is going on now on the P1, which for every variable you want to pull in, you have to keep adding 4 along with the RDLONG.
The equivalent on the Prop1 is 512 entries. But yep, a 64 entry table will likely be sufficient. Btw, it's 64 bytes, not longs.
Probably the biggest loser is address translation needed now where it wasn't before.
I was wrong. I thought that I used the lower hub ram and the MOVS instruction to do a RDLONG xxx,#lowhub in my faster interpreter.
However, I still think that the immediate mode for the RD/WR LONG/WORD/BYTE has some special applications.
That simplifies Work You need made to have SD bootable --
And are compatible with all types of OS systems.
And all other work to boot from SD are USERs work -- That fits his needs
Ps. That need only changing DOS signature text to any Yow will test for as VALID.
and if valid go to program read from MBR at address "60 Hex to 1AF"
On USER side
That Program will load X-sectors (that USER has control of that place) from place USER specify and transfer control to it.
After that a consensus was formed, in between the rowdy rabble, around the simple pointer, in block 0, pointing to a couple of contiguous blocks. This may extend to eight blocks via eight pointers in block 0.
SD wouldn't be a issue if Chip used a technology that allowed the use of Flash memory, so the Prop 2 is stuck with booting externally.
In addition there is no need for SD booting on a MCU. The people pushing this want to run a full blown OS like Linux or NetBSD on it. This is such a tiny minority of the market it's not worth it. Let these hobbyists whine or migrate to a Raspberry if they want to play with a OS
The above quote (as well as anything posted by Kye) is so far is the most realistic thing said in this thread.
Considering the P2 is to be positioned to the "professional" market the methodology of doing design by tossing ideas out to what is a hobbyist dominated forum is not only downright scary put somewhat off putting and something akin to doing dirty laundry in public.
My associates and I (as well as a few other companies I know) have been following this thread and the other one that dealt with EEPROM security for the P2 with a mix of both humour and horror.
The above quote is so far is the most realistic thing said in this thread.
Considering the P2 is to be positioned to the "professional" market the methodology of doing design by tossing ideas out to what is a hobbyist dominated forum is not only downright scary put somewhat off putting and something akin to doing dirty laundry in public.
My associates and I (as well as a few other companies I know) have been following this thread and the other one that dealt with EEPROM security for the P2 with a mix of both humour and horror.
But any good luck to Parallax.
Cheers
I kinda think this is idiotic, saying that there is no need for SD booting on a MCU. It depends on what that MCU is capable of. For me, I am pushing sd boot, and I DO NOT WANT TO RUN ANY OS ON THE P2. I want to design my own program, and have it utilize multimedia files, files that are WAYYYY too big to fit on a typical flash chip. I also want to be able to do recording of audio/video.
(do you realize how EXPENSIVE 1 gig of flash would be? not to mention all the address/data line I/O it would take up)
Id rather utilize the controller/logic already utilized inside sd cards, instead of using up 1/2 the P2 just for address/data lines just so I can have a 4 gig flash chip that cost me 8$ ? (more than the cost of a P1)
But you can buy 1 gig sd card for 1$ Or in bulk, for pennies on the dollar.
Why is everyone forgetting that the P2 is gonna be able to do some pretty cool MULTIMEDIA stuff?
Recording of audio, video, playback of audio video.. potienally even mpeg/avi/divx playback! For this one NEEDS large storage medium, which is expandable...
If you look at what people have done with the P1, you can see that lots of applications utilize VIDEO output, AUDIO output, DATA LOGGING, etc.. Somehow this trend is going to just stop with the P2?
Some of the things suggested here, seem to indicate that some contributors to this discussion might have alterior movives.
Say, a competitior of the P2... (raspberry pi.. cough cough...) or other chips out there...
Naturally it would benefit them if the P2 was less versatile, because the power of having 8 CORES blows away most other competition. Add to that the versatile ability to boot with eeprom, serial, AND SD...???
Can anyone say "DOMINATE?"
Yeup, yet again, we have the potential for another winner, yet again from Parallax.
(sorry all you arduino fans, but the P1 blew the doors off the arduino, imo)
If You say that methode I described in previous post are hobbyist ---- So You in same time SAY that all Operating systems and machines that use that one are hobbyist ones.
As all of them use that BOOT strap to boot theirs own handler for loading REAL OS boot system.
So before You say anything --- As least read what others have be write.
The above quote (as well as anything posted by Kye) is so far is the most realistic thing said in this thread.
Considering the P2 is to be positioned to the "professional" market the methodology of doing design by tossing ideas out to what is a hobbyist dominated forum is not only downright scary put somewhat off putting and something akin to doing dirty laundry in public.
My associates and I (as well as a few other companies I know) have been following this thread and the other one that dealt with EEPROM security for the P2 with a mix of both humour and horror.
Can you please publish a serial loader specification for P2?
The current P1 loader has certain issues that need to be avoided in P2.
Does not set TX to output on reset (causes garbage on loader's input).
Does not tolerate fast downloads from MAC (loader halts).
Lack of a published specification ! (guessing is not good).
Serial loading will be more painful with P2 because HUB RAM is 4x bigger than P1.
I have to assume that you realize this already and have done something about it.
If You say that methode I described in previous post are hobbyist ---- So You in same time SAY that all Operating systems and machines that use that one are hobbyist ones.
As all of them use that BOOT strap to boot theirs own handler for loading REAL OS boot system.
So before You say anything --- As least read what others have be write
It would appear that you also shoot from the hip without digesting what was written.
From my post "the methodology of doing design", now I do not recall saying anything about you or any other hobbyist so unless you are actually doing the design of the P2 or are part of the design team then that comment was not intended for you.
@Batang,
First of all, what's wrong with advice / analysis / suggestions from people, many of whom got into the use of the Propeller as a hobby, but have a day job where they are required to use other microcontrollers or have worked as consultants, some for a long time and successfully, or are involved in Computer Science or EE academia, etc.? This is a great pool of significant expertise that Parallax is drawing on for discussion and advice. It's tremendous that Chip is making use of it.
The SD card booting is a great idea as long as it can be done reliably and within ROM budget and it's not for running an OS. The Props need some kind of external persistent memory for booting since the manufacturing process used does not permit on-chip flash. It's never been said, but I'm sure the decision on process has to do with patents / licensing as well as costs and wanting a wide choice of foundries. Having an SD card makes it easy to do upgrades in the field, just by swapping SD cards which are cheap enough now so the old ones could even be discarded. The SD card could be used for logging or for storing images for display backgrounds or for sound files for aural feedback and instruction or for program overlays for complex applications. None of this involves an OS. Using a standard file system like FAT32 allows for easy SD card maintenance using standard desktop or laptop OSs.
I also understand the reasons for not going with internal flash but there have many good reasons put forward in this thread for not booting from a SD card and after 59 pages of this thread I am not going to list them all suffice to say the reasons for booting are whimsical at best (don't shoot the messenger).
Not to mention a monitor program, how retro is that:)
As I said in the original post "Good luck to Parallax".
Just a thought, 1 person makes a decision, 2 people have an argument, > 3 can't decide what time to have lunch.
Yes, Raw reads.Code is saved to SD card like any other file.
A util will read sectors used for this file (easy on a PC with its full OS)
and store pointers in the 440bytes reserved as bootcode in MBR.
If using 16bit for pointers, should be able to point to 220 sectors so no problem booting large code.
PropTool will save code AND do the rewrites of MBR in one step
And the good part is that boot file don't have to be continuous.
By reusing spi-code for flash boot, this SD boot should use less than 100 longs.
... suffice to say the reasons for booting are whimsical at best (don't shoot the messenger).
Okay, I'll reply to that one. I totally agree and I was against adding SD boot support initially. But it's only ROM and it's only a small amount of ROM and it's also not chewing up a bunch of Chip's time. We're the ones doing it, or more precisely Cluso, Ariba and Kye are the ones doing the coding.
It is many threads that complain that P1 dont have any simple Debugging possibility's --- Many raised of "Professionals" --- And Now You complain that why have that one.
As "Professional" one You describe You in one of previous thread --- I think You give 2 different versions of people that call them "Professionals"
I also understand the reasons for not going with internal flash but there have many good reasons put forward in this thread for not booting from a SD card and after 59 pages of this thread I am not going to list them all suffice to say the reasons for booting are whimsical at best (don't shoot the messenger).
Not to mention a monitor program, how retro is that:)
As I said in the original post "Good luck to Parallax".
Just a thought, 1 person makes a decision, 2 people have an argument, > 3 can't decide what time to have lunch.
I kinda agree that booting from SD adds complexity where maybe simplicity is best. That's why I suggested using fuse bits to have this feature turned off by default...
But, I've updated a few of my fance devices by putting a special file on a thumbdrive and rebooting...
This is way better than requiring customers to go out and buy a special USB Uart device and figuring out how to install software to use it...
It is many threads that complain that P1 dont have any simple Debugging possibility's --- Many raised of "Professionals" --- And Now You complain that why have that one.
As "Professional" one You describe You in one of previous thread --- I think You give 2 different versions of people that call them "Professionals"
@Sapieha,
Three things:
1. Dude take a pill and chill out.
2. I have no idea what you are talking about????
3. There 3 types of people in the world, those who can count and those who cannot.
>That's why I suggested using fuse bits to have this feature turned off by default...
How are you gonna get to the fuse?, don't tell me... PropPlug?.
So a $25 demo board needs a $15 prop plug to get started, that could be a price point where a hobbyist will not get started on PropII
The hobbyist is probably going to either have a demo board with a SPI flash chip on it or a Prop plug.
A demo board with SPI flash could be pre-programmed to have FAT or USB access, right?
Or, they could just do like Quickstart and include the USB Uart on the board...
>SPI flash chip on it.
But you can not get the SPI flash initiated without a PropPlug,
A $1 SD socket vs $15 Prop plug, the SD card can later be used for something useful.
PropPug not so much as PropII can do USB by itself once it got code in it.
And no to FTDI, Should not have to depend on a 3rd party chip to be able to boot.
QuickStart probably could have a $19.95 msrp if it was not for that kludge.
There is one problem Kye has repeatedly mentioned but it hasn't truly been discussed. It's one of those oh **** problems.
The support required for switching a SD card into a high speed transfer mode is a bit complicated and will cost ROM space. But the real humdinger is when the Prop is reset without dropping the power ... The SD card is still operating in a high speed mode and there is no specification on initialising cards from such a state (I think I'm getting this right). The various specs have always assumed the card is freshly powered up.
There is two options as I see it (keeping it mildly legit):
- Either stay in the initial low speed SPI mode (and this may still have init problems on a reset) saving some ROM.
- Or have the Prop also control the power pin of the SD card (costing another I/O pin).
Comments
I think a send checksum command was spoke of. I guess that would be good... but, the checksum itself could be corrupted during transfer...
Eh, anyway, I'm mentioning this because the P2 is targeted for professionals. Error handling needs to be present.
Thanks,
Chip: I don't think this is smart. The immediate hub address mode permits quick vector decoding (like I did on the spin interpreter). There are other smart uses of this immediate mode too. Otherwise, I have no preference wither way for ROM being hi or lo. Maybe you could use the second page ($200-$3FF) for the imediate mode on rd/wr to hub?
Please keep it simple. Again, we could load a better monitor just from the base monitor. So it should have CRCC or BCC for protection. Just the basic commands. Be careful this isn't seen as a hobby thing!
Please reserve me about 150 longs in ROM (I expect it will be less than this) to read some boot sectors (same length as for SPI would be best). Due to my workload others are testing the SD cards for me. My proposal does not care what OS, if any, is on the card. I believe this has the least risk and the best opportunity for future-proofing. It also happens to be the simplest and shortest.
It is just a few simple SD commands and we can read a group of sectors for the initial SD booting. It is already working, and I am looking for what SD cards already have in the MBR (sector 0) on the SD card.
I am just extremely busy until 1 september.
come on, Cluso99. Why the second guessing? you set the base pointer and then can get immediate access to 64 different longs. This is way better than what is going on now on the P1, which for every variable you want to pull in, you have to keep adding 4 along with the RDLONG.
Maybe not really a benefit, but if we're talking about objects, it gets rid of the notion of a precious area of fixed memory at the very beginning of HUB RAM that greedy objects are going to say that they need or else won't work.
One caveat I see about the beginning area being ROM, is that let's say we have the ability to still create a RAM or EEPROM file, is the area pertaining to the RAM still just going to be filled with 0's, so that there's a 1:1 correlation between the HUB ram addresses and the bytes in the file? 128 KB file loaded to 128 KB hub RAM instead of something weird like 126 KB file loaded into hub ram starting at address $800 ?
---
Separate idea:
I'm wondering for future designs, if the Cog RAM in Cog 0 could have that extra transistor to be able to be "reset" to the boot code. That way it doesn't live in the hub area at all. This was the next logical progression.
There was requests not to make the change the first time Chip suggested it. I believe one request came from Cluso. So, not second guessing at all.
The equivalent on the Prop1 is 512 entries. But yep, a 64 entry table will likely be sufficient. Btw, it's 64 bytes, not longs.
Probably the biggest loser is address translation needed now where it wasn't before.
However, I still think that the immediate mode for the RD/WR LONG/WORD/BYTE has some special applications.
As I will not post same info on 2 threads.
Look on this threads posts i made
SD Card Test (Please test - may be used for boot code for the Prop2)
That simplifies Work You need made to have SD bootable --
And are compatible with all types of OS systems.
And all other work to boot from SD are USERs work -- That fits his needs
Ps. That need only changing DOS signature text to any Yow will test for as VALID.
and if valid go to program read from MBR at address "60 Hex to 1AF"
On USER side
That Program will load X-sectors (that USER has control of that place) from place USER specify and transfer control to it.
But there is a desire to have more than half a block of code not to mention supporting partitionless booting. Cluso gave the initial description of the boot process back on page 19 - http://forums.parallax.com/showthread.php?141706-Propeller-II&p=1117420&viewfull=1#post1117420 which I promptly misread and thought he meant unallocated blocks after the MBR.
After that a consensus was formed, in between the rowdy rabble, around the simple pointer, in block 0, pointing to a couple of contiguous blocks. This may extend to eight blocks via eight pointers in block 0.
The above quote (as well as anything posted by Kye) is so far is the most realistic thing said in this thread.
Considering the P2 is to be positioned to the "professional" market the methodology of doing design by tossing ideas out to what is a hobbyist dominated forum is not only downright scary put somewhat off putting and something akin to doing dirty laundry in public.
My associates and I (as well as a few other companies I know) have been following this thread and the other one that dealt with EEPROM security for the P2 with a mix of both humour and horror.
But any good luck to Parallax.
Cheers
I kinda think this is idiotic, saying that there is no need for SD booting on a MCU. It depends on what that MCU is capable of. For me, I am pushing sd boot, and I DO NOT WANT TO RUN ANY OS ON THE P2. I want to design my own program, and have it utilize multimedia files, files that are WAYYYY too big to fit on a typical flash chip. I also want to be able to do recording of audio/video.
(do you realize how EXPENSIVE 1 gig of flash would be? not to mention all the address/data line I/O it would take up)
Id rather utilize the controller/logic already utilized inside sd cards, instead of using up 1/2 the P2 just for address/data lines just so I can have a 4 gig flash chip that cost me 8$ ? (more than the cost of a P1)
But you can buy 1 gig sd card for 1$ Or in bulk, for pennies on the dollar.
Why is everyone forgetting that the P2 is gonna be able to do some pretty cool MULTIMEDIA stuff?
Recording of audio, video, playback of audio video.. potienally even mpeg/avi/divx playback! For this one NEEDS large storage medium, which is expandable...
If you look at what people have done with the P1, you can see that lots of applications utilize VIDEO output, AUDIO output, DATA LOGGING, etc.. Somehow this trend is going to just stop with the P2?
Some of the things suggested here, seem to indicate that some contributors to this discussion might have alterior movives.
Say, a competitior of the P2... (raspberry pi.. cough cough...) or other chips out there...
Naturally it would benefit them if the P2 was less versatile, because the power of having 8 CORES blows away most other competition. Add to that the versatile ability to boot with eeprom, serial, AND SD...???
Can anyone say "DOMINATE?"
Yeup, yet again, we have the potential for another winner, yet again from Parallax.
(sorry all you arduino fans, but the P1 blew the doors off the arduino, imo)
Booting from a SD card and using a SD card for multimedia file storage are not the same thing.
File storage with a SD card is done all the time with various MCU's and geewiz even my smartphone does it.
Cheers
PS.
Clock Loop
id·i·ot·ic [id-ee-ot-ik]
adjective
1. of, pertaining to, or characteristic of an idiot.
2. senselessly foolish or stupid: an idiotic remark.
Nice.
If You say that methode I described in previous post are hobbyist ---- So You in same time SAY that all Operating systems and machines that use that one are hobbyist ones.
As all of them use that BOOT strap to boot theirs own handler for loading REAL OS boot system.
So before You say anything --- As least read what others have be write.
Can you please publish a serial loader specification for P2?
The current P1 loader has certain issues that need to be avoided in P2.
I have to assume that you realize this already and have done something about it.
Thanks,
--Steve
It would appear that you also shoot from the hip without digesting what was written.
From my post "the methodology of doing design", now I do not recall saying anything about you or any other hobbyist so unless you are actually doing the design of the P2 or are part of the design team then that comment was not intended for you.
Cheers
First of all, what's wrong with advice / analysis / suggestions from people, many of whom got into the use of the Propeller as a hobby, but have a day job where they are required to use other microcontrollers or have worked as consultants, some for a long time and successfully, or are involved in Computer Science or EE academia, etc.? This is a great pool of significant expertise that Parallax is drawing on for discussion and advice. It's tremendous that Chip is making use of it.
The SD card booting is a great idea as long as it can be done reliably and within ROM budget and it's not for running an OS. The Props need some kind of external persistent memory for booting since the manufacturing process used does not permit on-chip flash. It's never been said, but I'm sure the decision on process has to do with patents / licensing as well as costs and wanting a wide choice of foundries. Having an SD card makes it easy to do upgrades in the field, just by swapping SD cards which are cheap enough now so the old ones could even be discarded. The SD card could be used for logging or for storing images for display backgrounds or for sound files for aural feedback and instruction or for program overlays for complex applications. None of this involves an OS. Using a standard file system like FAT32 allows for easy SD card maintenance using standard desktop or laptop OSs.
http://www.moty22.co.uk/sd.php
In 680 bytes, he does read and write to SD with no file system at all...
I also understand the reasons for not going with internal flash but there have many good reasons put forward in this thread for not booting from a SD card and after 59 pages of this thread I am not going to list them all suffice to say the reasons for booting are whimsical at best (don't shoot the messenger).
Not to mention a monitor program, how retro is that:)
As I said in the original post "Good luck to Parallax".
Just a thought, 1 person makes a decision, 2 people have an argument, > 3 can't decide what time to have lunch.
Cheers
A util will read sectors used for this file (easy on a PC with its full OS)
and store pointers in the 440bytes reserved as bootcode in MBR.
If using 16bit for pointers, should be able to point to 220 sectors so no problem booting large code.
PropTool will save code AND do the rewrites of MBR in one step
And the good part is that boot file don't have to be continuous.
By reusing spi-code for flash boot, this SD boot should use less than 100 longs.
Okay, I'll reply to that one. I totally agree and I was against adding SD boot support initially. But it's only ROM and it's only a small amount of ROM and it's also not chewing up a bunch of Chip's time. We're the ones doing it, or more precisely Cluso, Ariba and Kye are the ones doing the coding.
As "Professional" one You describe You in one of previous thread --- I think You give 2 different versions of people that call them "Professionals"
But, I've updated a few of my fance devices by putting a special file on a thumbdrive and rebooting...
This is way better than requiring customers to go out and buy a special USB Uart device and figuring out how to install software to use it...
@Sapieha,
Three things:
1. Dude take a pill and chill out.
2. I have no idea what you are talking about????
3. There 3 types of people in the world, those who can count and those who cannot.
Cheers
How are you gonna get to the fuse?, don't tell me... PropPlug?.
So a $25 demo board needs a $15 prop plug to get started, that could be a price point where a hobbyist will not get started on PropII
A demo board with SPI flash could be pre-programmed to have FAT or USB access, right?
Or, they could just do like Quickstart and include the USB Uart on the board...
But you can not get the SPI flash initiated without a PropPlug,
A $1 SD socket vs $15 Prop plug, the SD card can later be used for something useful.
PropPug not so much as PropII can do USB by itself once it got code in it.
And no to FTDI, Should not have to depend on a 3rd party chip to be able to boot.
QuickStart probably could have a $19.95 msrp if it was not for that kludge.
The support required for switching a SD card into a high speed transfer mode is a bit complicated and will cost ROM space. But the real humdinger is when the Prop is reset without dropping the power ... The SD card is still operating in a high speed mode and there is no specification on initialising cards from such a state (I think I'm getting this right). The various specs have always assumed the card is freshly powered up.
There is two options as I see it (keeping it mildly legit):
- Either stay in the initial low speed SPI mode (and this may still have init problems on a reset) saving some ROM.
- Or have the Prop also control the power pin of the SD card (costing another I/O pin).
A lot of testing to come me thinks ...