Lots of us could write that. Seems a non-issue to me, and it's really only for Windows, and for windows where somebody doesn't already have a prop. Since they will, a prop can just setup the boot partition and write out all the blocks. Lots of us could write that too.
But you aren't considering the end-user, the customer of Parallax's customer. If you use an SD card to distribute firmware upgrades, it has to be simple: Drag and drop a file called AUTORUN.PEX to the SD card.
I posed an option to Chip to make all of this debate go away: Offer the P2 with a stacked die SPI flash of 1Mbit in size. Then the whole strawman argument about SD and the cost of SPI flash is moot.
The truth is that any vendor who wants cheap onboard storage will use eMMC, just like the smartphone vendors. With eMMC you get more-or-less the SD protocol we discuss and an embedded formfactor that doesn't require a [relatively] expensive socket.
Also, "cheap" sockets are just that, cheap. You can't argue that low cost sockets are going to provide high quality failure free usage.
But you aren't considering the end-user, the customer of Parallax's customer. If you use an SD card to distribute firmware upgrades, it has to be simple: Drag and drop a file called AUTORUN.PEX to the SD card.
The equipment comes with a bootable SD card, maybe even a spare. The boot loader on the card is unlikely to be changed. It's the main program that is the one getting the updates. So, dragging update files on to those, already bootable, SD cards works a treat.
If the rare occurrence of the boot loader needing a fix then mailing out a replacement SD card is a small price to pay.
If mass update of boot loader is required then the situation is a bit sticky. Time to invest in detailed step by step instructions for customer using tool to update boot loader from a file.
Here is the next part - the simplified load section. It does not require mounting the SD card... (error code and display is still their atm to provide feedback)
As usual, change the clock freq and the SD pins to suit. P2Boot_120e - Archive [Date 2012.08.18 Time 17.26].zip
Having standard PC compatible partition ---> Simplify placing of user files on that SD
Sapieha: This will work with my method, and all others too! In fact, currently my card has many files in FAT 16 or 32 (not sure which here) and I just boot one of those files that is being pointed to by the MBR.
Well, they have options, and isn't this about baseline options?
Lots of stuff uses lots of ways to update. Net connection, USB stick, SD card, file on CD / DVD, serial, etc... Some of it is simple, some of it's not, some of it is simple to one set of users, some of it is simple to another set, etc...
What the customer of Parallax does for their customer is a different problem space. Parallax offering SD boot is simply offering SD boot. The best case is to offer a standard SD boot, if it's done at all, and the standard is a partition, and that's seen all over the place now, with others choosing SD clearly seeing a partition as the way to go, likely because doing that is the standard, best practice.
Seems to me, we are trying to solve a problem that isn't posed yet when we talk about "drag this file here" kinds of things. Besides, simple varies considerably, and it depends on the market dynamics and customer demographics too.
Simple could be, insert SD card, run this program and watch for the "Update Successful !" message, or maybe even the language neutral happy face or green light icon. Doesn't matter much, does it? What does matter is that the process is lean and consistent, and that's part of the value added in product design, one layer up from the discussion we are having right now.
Here's something really interesting!
I work with engineers all the time in a support role for some really complex software. (high end CAD) These guys can drive that stuff like no other, getting into no end of trouble, authoring little programs, making complex math expressions, constraints, geometries, etc... Want to know the absolute number one issue they have? Biggest support burden?
Copying a file to update a license. They just can't do it. I am regularly stunned at how badly people can botch just copying a file.
Now, another program I have the same involvement in uses an exe for the same purpose. There are next to ZERO support issues with that. They get the thing somehow, double click it, and it's done.
And that's college educated engineers. Smart folks. "Simple" is often quite difficult to pin down, and we aren't there anyway. We are at, "how to boot a P2?"
The rest of the decision tree is pretty simple:
SD or not?
Boot standard or not? Boot completely, or not?
A partition allows for a standard boot that is also a complete boot, image being no different than it would be for some other boot method. Is there any real value added by doing otherwise?
I can't see any. It's really hard to justify a hack in the ROM, when we've got the ability to just do it standard. If we do it standard, and there are issues, we've got the standards to fall back on, meaning no expectations were set that didn't need to be and that's a very optimal support case.
Given a standard use of the media, Parallax and it's community simply publish a reference implementation and it's done! No expectations were set that didn't need to be. Optimal over the short and long haul.
When somebody asks, "Why?" a standard answer will make great sense. We are talking about a pro chip, right? Well, what pro really wants a ROM with a hack in it? Seriously? It's that kind of thing that's the rub here: ...just because it can be done, or is working now, doesn't mean it should be done kind of thing.
And that just because it can be done question is still technically on the table for SD entirely. Boot SD or not? Maybe the ROM space we have won't actually play out, and SD isn't on the table. No loss. I would absolutely take it off the table, if it's marginal, or a hack just barely got it in.
Kye is saying something really subtle. It will just fit, barely. But it's standard, just fit barely, not a hack that just fits barely, and the difference is a robust, solid, design that is defensible over the longer haul vs, "it worked when we built it."
Remember Chip's letter about P1. He put his name on it saying, "this thing rocks" and he cited the attention to these kinds of matters as a big part of why. That expectation is already set, meaning it should be met on P2, or it doesn't mean much.
From there, the customers of Parallax can decide what system values make sense, and if they think poorly of SD, they can skip it. If they like SD, they can sort out how they want to persue updating a standard SD boot configuration, and given it's a standard one, they will require the least amount of documentation in order to do just that.
That's safe. I'm thinking there's nothing wrong with putting the special string at start of MBR either. If anything else modifies the MBR it'll either leave the first 446 bytes untouched or it'll replace the lot.
Because one of the wiki shows a use of the MBR sector #0 as a VBR with various descriptors used and the boot portion being at a variable offset. Therefore I chose to ensure it was within the bootable section of the MBR. Here is that wiki page http://en.wikipedia.org/wiki/File_Allocation_Table
Say that somebody doesn't want files written to that SD card. They want RAW data. If a partition is in use, no brainer. They can do what they will with the rest of the card. When it's mounted in a PC, it shows as just blank media.
That's every bit as valid as "just drag and drop file here" is.
A partition does both equally well. Poking around in the MBR doesn't.
....
Why such a commotion with what filesystem/structure needs to be on the SD card??? Use the MBR record as a pointer(s). This IS WORKING NOW !!! I posted code and so has ariba. We both only have to trim the code to simplified pasm. Our concepts are very similar.
.....
Clusso, my code is already trimmed to 151 longs in PASM 1 code. The difference is I test only one long instead of a 12 char string, and this at location 400.
This new version combines the shortcut in the MBR (or what else is at sector 0) with the sectorwise searching for a signature at the begin of a boot-file. It does work here with SD cards (<=2GB) , and SDHC cards (>= 4GB).
For a bootable SD card you copy the bootfile to the fresh formated SD card - that was it.
Then the bootloader finds no shortcut in the MBR so it searches up to sector 19000 for a sector with the signature. This takes several seconds.
So if you want it faster use a (Spin)- Utility to write the shortcut, and now it boots in a few ms.
You can overwrte the boot file everytime with new code if it fits in the already allocated clusters. If you want disable booting you need to overwrite it with a file with wrong signature, just deleting will not help.
I have changed the place of the MBR shortcut a bit, so I have also attached the new utility.
' Minimal SD booter Test
' ----------------------
' by Andy Schenk, Insonix
con
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
do = 8 'sd pins
clk = 9
di = 10
cs = 11
obj dbg: "FullDuplexSerial"
pub Main : i | tm
'
' This Spin code is not part of the boot code, it
' just starts the PASM cog and shows the result
'
waitcnt(clkfreq*3+cnt)
dbg.start(31,30,0,115200)
cognew(@entry, 0)
dbg.str(string("searching file...",13))
tm := cnt
repeat until (i := long[$7000-4])
if i < 0
dbg.str(string("booting failed: "))
dbg.dec(i)
if i== -10
dbg.str(string(13,"(no boot file)"))
if i== -13
dbg.str(string(13,"(timeout SD access)"))
else
dbg.str(string("found at sector: "))
dbg.dec(i)
dbg.str(string(" in ms:"))
dbg.dec((cnt-tm)/(clkfreq/1000))
dbg.tx(13)
byte[$707F] := 0 'show first 127 chars
dbg.str($7000)
repeat
dat
org
entry
' set up
mov blocksh,#0
or outa,clkmask
mov dira,outmask 'pins
neg phsb,#1
mov ctr2,onek '1000 x High for init
oneloop
call #sendiohi
djnz ctr2,#oneloop
mov starttime,cnt
mov ctr2,#9 'try a few times
reslp mov cmdo,#0
mov cmdp,#0
call #cmd
cmp accb,#1 wz
if_z jmp #tsthc
djnz ctr2,#reslp
tsthc mov cmdo,#8 'test if SD2
mov cmdp,#$1AA
call #cmd
cmp accb,#1 wz
if_nz jmp #resok '< no
mov ctr,#32
call #sendiocnt 'read volt
inilp mov cmdo,#55
mov cmdp,#0
call #cmd
mov cmdo,#41
mov cmdp,bit30
call #cmd
cmp accb,#0 wz
if_nz jmp #inilp
mov cmdo,#58 'test if SDHC
mov cmdp,#0
call #cmd
mov ctr,#32
call #sendiocnt
or outa,csmask
test accb,bit30 wz
if_z mov blocksh,#9
jmp #begin
resok or outa,csmask
call #sendiohi
initloop
mov cmdo,#55
call #cmd
mov cmdo,#41
call #cmd
cmp accb,#1 wz
if_z jmp #initloop
mov blocksh,#9 '0=SDHC 9=SD
' search signature and startsector in sector 0
begin mov blocknr,#0
mov bufad,hubbuf
call #rblock 'read sector 0
mov bufad,hubbuf
add bufad,#400
rdlong accb,bufad 'boot signature at 400 ?
cmp accb,signatur0 wz
if_nz jmp #search 'no signature: search sector
add bufad,#4
rdlong blocknr,bufad 'read boot startsector at 404
' search sector with boot file signature
search mov bufad,hubbuf
call #rblock
rdlong accb,hubbuf
cmp accb,signaturFile wz
if_z jmp #found
add blocknr,#1
cmp blocknr,lastblock wc
if_b jmp #search
neg accb,#10 'not found error: -10
fback sub hubbuf,#4
wrlong accb,hubbuf
halt jmp #halt
found mov lastblock,#3 'load boot code (only 3 sectors here)
:load call #rblock
djnz lastblock,#:load
mov accb,blocknr
jmp #fback 'okay
rblock
mov ctr2,sectorsz 'read block
mov starttime,cnt
mov cmdo,#17
mov cmdp,blocknr
call #cmd
call #readresp
rbyte
mov accb,#8
andn outa,clkmask
or outa,clkmask
test domask,ina wc
addx acca,acca
djnz accb,#rbyte+1
wrbyte acca,bufad
add bufad,#1
djnz ctr2,#rbyte
call #sendiohi
call #sendiohi
or outa,csmask
rblock_ret ret
sendio
rol phsb,#24 'SPI routines
sendiohi
mov ctr,#8
sendiocnt
mov accb,#0
bit andn outa,clkmask
rol phsb,#1 wc
muxc outa,dimask
or outa,clkmask
test domask,ina wc
addx accb,accb
djnz ctr,#bit
sendio_ret
sendiohi_ret
sendiocnt_ret
ret
checktime
mov duration,cnt
sub duration,starttime
cmp duration,clockfreq wc
checktime_ret
if_c ret
neg accb,#13 'timeout error: -13
jmp #fback
cmd
cmp cmdo,#41 wz
if_z or outa,csmask
nop
andn outa,csmask
neg phsb,#1
call #sendiohi
mov phsb,cmdo
add phsb,#$40
call #sendio
mov phsb,cmdp
shl phsb,blocksh
call #sendiohi
call #sendiohi
call #sendiohi
call #sendiohi
cmp cmdo,#8 wz
if_z mov phsb,#$87
if_nz mov phsb,#$95
call #sendio
cmp cmdo,#12 wz
if_z neg phsb,#1
if_z call #sendiohi
readresp
neg phsb,#1
call #sendiohi
call #checktime
cmp accb,#$ff wz
if_z jmp #readresp
cmd_ret
readresp_ret
ret
clockfreq long 80_000_000
onek long 1000
sectorsz long 512
bit30 long 1<<30
domask long 1<<do
csmask long 1<<cs
clkmask long 1<<clk
dimask long 1<<di
outmask long 1<<clk | 1<<di | 1<<cs
lastblock long 19000
signatur0 byte "BOOT"
signaturFile byte "P2BO"
hubbuf long $7000
acca res 1
accb res 1
cmdo res 1
cmdp res 1
ctr res 1
ctr2 res 1
starttime res 1
duration res 1
bufad res 1
blocknr res 1
blocksh res 1
Andy
Edit: removed the copyright. The code is based on the FSRW driver from rokicki and lonesock, but havy modified and portet to PASM by me.
Because one of the wiki shows a use of the MBR sector #0 as a VBR with various descriptors used and the boot portion being at a variable offset. Therefore I chose to ensure it was within the bootable section of the MBR. Here is that wiki page http://en.wikipedia.org/wiki/File_Allocation_Table
I like the idea of supporting partitionless booting. Very cool.
Clusso, my code is already trimmed to 151 longs in PASM 1 code. The difference is I test only one long instead of a 12 char string, and this at location 400.
This new version combines the shortcut in the MBR (or what else is at sector 0) with the sectorwise searching for a signature at the begin of a boot-file. It does work here with SD cards (<=2GB) , and SDHC cards (>= 4GB).
For a bootable SD card you copy the bootfile to the fresh formated SD card - that was it.
Then the bootloader finds no shortcut in the MBR so it searches up to sector 19000 for a sector with the signature. This takes several seconds.
So if you want it faster use a (Spin)- Utility to write the shortcut, and now it boots in a few ms.
You can overwrte the boot file everytime with new code if it fits in the already allocated clusters. If you want disable booting you need to overwrite it with a file with wrong signature, just deleting will not help.
I have changed the place of the MBR shortcut a bit, so I have also attached the new utility.
' Minimal SD booter Test
' ----------------------
' (c)2012 Andy Schenk, Insonix
con
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
do = 8 'sd pins
clk = 9
di = 10
cs = 11
obj dbg: "FullDuplexSerial"
pub Main : i | tm
'
' This Spin code is not part of the boot code, it
' just starts the PASM cog and shows the result
'
waitcnt(clkfreq*3+cnt)
dbg.start(31,30,0,115200)
cognew(@entry, 0)
dbg.str(string("searching file...",13))
tm := cnt
repeat until (i := long[$7000-4])
if i < 0
dbg.str(string("booting failed: "))
dbg.dec(i)
if i== -10
dbg.str(string(13,"(no boot file)"))
if i== -13
dbg.str(string(13,"(timeout SD access)"))
else
dbg.str(string("found at sector: "))
dbg.dec(i)
dbg.str(string(" in ms:"))
dbg.dec((cnt-tm)/(clkfreq/1000))
dbg.tx(13)
byte[$707F] := 0 'show first 127 chars
dbg.str($7000)
repeat
dat
org
entry
' set up
mov blocksh,#0
or outa,clkmask
mov dira,outmask 'pins
neg phsb,#1
mov ctr2,onek '1000 x High for init
oneloop
call #sendiohi
djnz ctr2,#oneloop
mov starttime,cnt
mov ctr2,#9 'try a few times
reslp mov cmdo,#0
mov cmdp,#0
call #cmd
cmp accb,#1 wz
if_z jmp #tsthc
djnz ctr2,#reslp
tsthc mov cmdo,#8 'test if SD2
mov cmdp,#$1AA
call #cmd
cmp accb,#1 wz
if_nz jmp #resok '< no
mov ctr,#32
call #sendiocnt 'read volt
inilp mov cmdo,#55
mov cmdp,#0
call #cmd
mov cmdo,#41
mov cmdp,bit30
call #cmd
cmp accb,#0 wz
if_nz jmp #inilp
mov cmdo,#58 'test if SDHC
mov cmdp,#0
call #cmd
mov ctr,#32
call #sendiocnt
or outa,csmask
test accb,bit30 wz
if_z mov blocksh,#9
jmp #begin
resok or outa,csmask
call #sendiohi
initloop
mov cmdo,#55
call #cmd
mov cmdo,#41
call #cmd
cmp accb,#1 wz
if_z jmp #initloop
mov blocksh,#9 '0=SDHC 9=SD
' search signature and startsector in sector 0
begin mov blocknr,#0
mov bufad,hubbuf
call #rblock 'read sector 0
mov bufad,hubbuf
add bufad,#400
rdlong accb,bufad 'boot signature at 440 ?
cmp accb,signatur0 wz
if_nz jmp #search 'no signature: search sector
add bufad,#4
rdlong blocknr,bufad 'read boot startsector at 444
' search sector with boot file signature
search mov bufad,hubbuf
call #rblock
rdlong accb,hubbuf
cmp accb,signaturFile wz
if_z jmp #found
add blocknr,#1
cmp blocknr,lastblock wc
if_b jmp #search
neg accb,#10 'not found error: -10
fback sub hubbuf,#4
wrlong accb,hubbuf
halt jmp #halt
found mov lastblock,#3 'load boot code (only 3 sectors here)
:load call #rblock
djnz lastblock,#:load
mov accb,blocknr
jmp #fback 'okay
rblock
mov ctr2,sectorsz 'read block
mov starttime,cnt
mov cmdo,#17
mov cmdp,blocknr
call #cmd
call #readresp
rbyte
mov accb,#8
andn outa,clkmask
or outa,clkmask
test domask,ina wc
addx acca,acca
djnz accb,#rbyte+1
wrbyte acca,bufad
add bufad,#1
djnz ctr2,#rbyte
call #sendiohi
call #sendiohi
or outa,csmask
rblock_ret ret
sendio
rol phsb,#24 'SPI routines
sendiohi
mov ctr,#8
sendiocnt
mov accb,#0
bit andn outa,clkmask
rol phsb,#1 wc
muxc outa,dimask
or outa,clkmask
test domask,ina wc
addx accb,accb
djnz ctr,#bit
sendio_ret
sendiohi_ret
sendiocnt_ret
ret
checktime
mov duration,cnt
sub duration,starttime
cmp duration,clockfreq wc
checktime_ret
if_c ret
neg accb,#13 'timeout error: -13
jmp #fback
cmd
cmp cmdo,#41 wz
if_z or outa,csmask
nop
andn outa,csmask
neg phsb,#1
call #sendiohi
mov phsb,cmdo
add phsb,#$40
call #sendio
mov phsb,cmdp
shl phsb,blocksh
call #sendiohi
call #sendiohi
call #sendiohi
call #sendiohi
cmp cmdo,#8 wz
if_z mov phsb,#$87
if_nz mov phsb,#$95
call #sendio
cmp cmdo,#12 wz
if_z neg phsb,#1
if_z call #sendiohi
readresp
neg phsb,#1
call #sendiohi
call #checktime
cmp accb,#$ff wz
if_z jmp #readresp
cmd_ret
readresp_ret
ret
clockfreq long 80_000_000
onek long 1000
sectorsz long 512
bit30 long 1<<30
domask long 1<<do
csmask long 1<<cs
clkmask long 1<<clk
dimask long 1<<di
outmask long 1<<clk | 1<<di | 1<<cs
lastblock long 19000
signatur0 byte "BOOT"
signaturFile byte "P2BO"
hubbuf long $7000
acca res 1
accb res 1
cmdo res 1
cmdp res 1
ctr res 1
ctr2 res 1
starttime res 1
duration res 1
bufad res 1
blocknr res 1
blocksh res 1
Say that somebody doesn't want files written to that SD card. They want RAW data. If a partition is in use, no brainer. They can do what they will with the rest of the card. When it's mounted in a PC, it shows as just blank media.
Are you meaning having two partitions? One for large raw boot image and the other, as filesystem, just for remaining spare space? Or something else?
If only for a large boot image then extending the FAT partition's reserved space can do it cleanly.
You can overwrte the boot file everytime with new code if it fits in the already allocated clusters. If you want disable booting you need to overwrite it with a file with wrong signature, just deleting will not help.
I've just realised what the kludge is with this approach. Someone not aware of how this file is being used might make the mistake of messing with it as a standard file. I guess, if it's marked as system file that might reduce this risk.
EDIT: Of course, this technicality doesn't affect the ROM code. It's doesn't care where the blocks are.
Andy: I missed your previous code because I downloaded your file and looked at that. Then realised that the posted code was not included in the zip file - perhaps you may like to add it in.
Can we first get a consensus of what the MBR shall be modified to???
1. Offset for parameter(s)? I have chosen $180. Andy has chosen 400decimal. My preference is a hex value. I am also happy with $100 which also seems to be fine. Thoughts???
2. The identifier? I agree that 1 long is probably sufficient. So let us on what that long shall be??? Any suggestions??? "P2x"+$0 (i.e. a string?) or a hex value???
3. The pointer? a long to the first boot code sector??? Do we require a second sector pointer or just use the first +1. From what I understand has been said, the Flash uses 1024 bytes initially, so we should conform to this.
4. If we add Andy's search if this fails, what should the search string/long/whatever be???
If we can at least agree with this then we can interchange each others code to test without having to re-write the MBR each time.
Maybe you need 3 sectors. The first has the 'long' identifier and the next 2 have the 1024 bytes we need to boot. While I am sure we could get away with 1020 bytes we would then have to remove the 4 bytes and substitute with zeros. Maybe just make the identifier with zeros. Your thoughts??? But then we have to play with the compiler output file. Not as simple as just copying a file to whatever file system is on the SD card.
I think the scan should be a fallback if the MBR pointer is not found.
I want to ensure that the sdspiFemto.spin pasm code that I use has the same SD commands because this is quite a proven set of code. I have been looking at your asm code to see the order of commands you issue to the SD card.
We will need to ensure that the P2 pasm driver code (implementing the SPI commands and sector reads) is not too fast for the SD cards. It is only a boot so it can be slower. We can use the NOP #n instruction nicely
@Cluso
I think the details (signature, position) must be defined by Parallax / Chip, if it ever gets implemented.
I don't get your point 3. If you have the file found you can read a lot of sectors, they are all contiguous if written after formating, or minimally contiguous up to the cluster size if written later.
As I said before: this code is not meant as the final solution, just to show that it is possible to fit an SD bootloader in the remaining ROM space.
@evanh
The idea for the searching is that you don't need any tools on the PC, and can boot from a SD card without a Spin IDE, a PropPlug or such things.
If the bootcode writes the shortcut to itself automatic, then only the first boot takes a long time.
What I could really do with is help to strip the eeprom code from this pasm file so it is easier to see what is really being done. Here is the file... fsrwsdspiFemto_rr005e.spin
While I am certainly capable of writing the SPI code for the SD card, I haven't bothered because it was already done for me. I use this code currently so I am confident it works quite well. All that is required is to strip the eeprom code to see what it is really doing. We can add some extra possible code such as Andy has (SDHC cards etc if it's not there now) but I don't want to break what has already been done without a very good reason.
In other words, while it may be easier to start afresh, there is more risk. I am not prepared to put my name to that risk, and I presume Chip/Parallax will not be prepared either. It must be failsafe, so each extension must be built upon the failure of the previous sequence.
If you have the file found you can read a lot of sectors, they are all contiguous if written after formating, or minimally contiguous up to the cluster size if written later.
Bad to assume that without tool to ensure it. What's more that file would need careful maintenance on updates to ensure continued integrity. ... Which leads to the flaw in searching.
Bad to assume that without tool to ensure it. What's more that file would need careful maintenance on updates to ensure continued integrity. ... Which leads to the flaw in searching.
We can add some extra possible code such as Andy has (SDHC cards etc if it's not there now) but I don't want to break what has already been done without a very good reason.
The very good reason is that fsrwFemto not supports SDHC cards, and it will be hard to strip this code down to the needed size.
To find an initialization code that works with many SD and SDHC cards and is short enough is the actual challenge for the ROM bootcode (as Kye has said so many times).
IAn SD bootcode that not supports SDHC cards is of no use. It's hard to find SD cards <= 2GB today. In a few years when the Prop2 comes it will be even harder...
DOS --- ALWAYS need freshly formated DISK to be made it bootable.
Yes, tools to ensure correct layout. Which is what we need also.
Plus I believe DOS had an INIT.EXE command for refreshing the partition boot data independent of the MBR - which was managed by FDISK.EXE. Both commands allowed for modifying without destroying the partition contents.
Yes, tools to ensure correct layout. Which is what we need also.
Plus I believe DOS had an INIT.EXE command for refreshing the partition boot data independent of the MBR - which was managed by FDISK.EXE. Both commands allowed for modifying without destroying the partition contents.
Agreed Andy, we need to support SDHC cards as <= 2GB cards are likely to become extinct some time in the future, although for now they are required by a lot of devices. But I want to ensure we can do both.
You said That Chip will use PARTITION table info for boot.
That is not alway true on SD.----
As You can see from attached pictures ---- My SD that is 2BG and bootable with NT not have in Partition entries any values.
--- Most of BOOT sector have empty space but still You can see on left side of picture that it have all needed files to boot NT
So it is most safe to calculate them LOOK on
> "Boot Sector FAT.jpg"
It is values that needs to find it.
Functions in ROM should be really reliable and predictable things. At this point, having an EEPROM/FLASH for $0.50 isn't a big deal if it has an SD loader in it. At this point, I think I'd rather have the RAM back or a monitor application.
Very interesting conversation of how to do this in so little memory though...
I'd be happy to throw in my 2 cents worth on this whole matter of booting but I'm sure with all you cooks in the kitchen that we will eventually have something edible
Here's quick question in another direction altogether. Some mention has been made about FFTs on the current Prop which I am not interested in for this purpose but I am interested in knowing how well an FFT could perform on the Prop II in the audio spectrum. Could P2 be used in place of a DSP for equalizing and compression etc. Any ideas?
I am interested in knowing how well an FFT could perform on the Prop II in the audio spectrum. Could P2 be used in place of a DSP for equalizing and compression etc. Any ideas?
Absolutely! There is a specific MAC instruction, and supporting 64 bit accumulator. It'll fly
EDIT: Make that accumulators, plural, there is two. And a bunch of special instructions for manipulating them. This multiplier is separate from the general purpose one it seems. It's single cycle and takes 24 bit input with results always going to one of the special accumulators.
EDIT2: Or maybe the full multiple instruction loops on the 24 bit multiplier to get the extra bits.
Comments
But you aren't considering the end-user, the customer of Parallax's customer. If you use an SD card to distribute firmware upgrades, it has to be simple: Drag and drop a file called AUTORUN.PEX to the SD card.
I posed an option to Chip to make all of this debate go away: Offer the P2 with a stacked die SPI flash of 1Mbit in size. Then the whole strawman argument about SD and the cost of SPI flash is moot.
The truth is that any vendor who wants cheap onboard storage will use eMMC, just like the smartphone vendors. With eMMC you get more-or-less the SD protocol we discuss and an embedded formfactor that doesn't require a [relatively] expensive socket.
Also, "cheap" sockets are just that, cheap. You can't argue that low cost sockets are going to provide high quality failure free usage.
The equipment comes with a bootable SD card, maybe even a spare. The boot loader on the card is unlikely to be changed. It's the main program that is the one getting the updates. So, dragging update files on to those, already bootable, SD cards works a treat.
If the rare occurrence of the boot loader needing a fix then mailing out a replacement SD card is a small price to pay.
PS: Totally agree on the socket issue.
As usual, change the clock freq and the SD pins to suit.
P2Boot_120e - Archive [Date 2012.08.18 Time 17.26].zip
Lots of stuff uses lots of ways to update. Net connection, USB stick, SD card, file on CD / DVD, serial, etc... Some of it is simple, some of it's not, some of it is simple to one set of users, some of it is simple to another set, etc...
What the customer of Parallax does for their customer is a different problem space. Parallax offering SD boot is simply offering SD boot. The best case is to offer a standard SD boot, if it's done at all, and the standard is a partition, and that's seen all over the place now, with others choosing SD clearly seeing a partition as the way to go, likely because doing that is the standard, best practice.
Seems to me, we are trying to solve a problem that isn't posed yet when we talk about "drag this file here" kinds of things. Besides, simple varies considerably, and it depends on the market dynamics and customer demographics too.
Simple could be, insert SD card, run this program and watch for the "Update Successful !" message, or maybe even the language neutral happy face or green light icon. Doesn't matter much, does it? What does matter is that the process is lean and consistent, and that's part of the value added in product design, one layer up from the discussion we are having right now.
Here's something really interesting!
I work with engineers all the time in a support role for some really complex software. (high end CAD) These guys can drive that stuff like no other, getting into no end of trouble, authoring little programs, making complex math expressions, constraints, geometries, etc... Want to know the absolute number one issue they have? Biggest support burden?
Copying a file to update a license. They just can't do it. I am regularly stunned at how badly people can botch just copying a file.
Now, another program I have the same involvement in uses an exe for the same purpose. There are next to ZERO support issues with that. They get the thing somehow, double click it, and it's done.
And that's college educated engineers. Smart folks. "Simple" is often quite difficult to pin down, and we aren't there anyway. We are at, "how to boot a P2?"
The rest of the decision tree is pretty simple:
SD or not?
Boot standard or not? Boot completely, or not?
A partition allows for a standard boot that is also a complete boot, image being no different than it would be for some other boot method. Is there any real value added by doing otherwise?
I can't see any. It's really hard to justify a hack in the ROM, when we've got the ability to just do it standard. If we do it standard, and there are issues, we've got the standards to fall back on, meaning no expectations were set that didn't need to be and that's a very optimal support case.
Given a standard use of the media, Parallax and it's community simply publish a reference implementation and it's done! No expectations were set that didn't need to be. Optimal over the short and long haul.
When somebody asks, "Why?" a standard answer will make great sense. We are talking about a pro chip, right? Well, what pro really wants a ROM with a hack in it? Seriously? It's that kind of thing that's the rub here: ...just because it can be done, or is working now, doesn't mean it should be done kind of thing.
And that just because it can be done question is still technically on the table for SD entirely. Boot SD or not? Maybe the ROM space we have won't actually play out, and SD isn't on the table. No loss. I would absolutely take it off the table, if it's marginal, or a hack just barely got it in.
Kye is saying something really subtle. It will just fit, barely. But it's standard, just fit barely, not a hack that just fits barely, and the difference is a robust, solid, design that is defensible over the longer haul vs, "it worked when we built it."
Remember Chip's letter about P1. He put his name on it saying, "this thing rocks" and he cited the attention to these kinds of matters as a big part of why. That expectation is already set, meaning it should be met on P2, or it doesn't mean much.
From there, the customers of Parallax can decide what system values make sense, and if they think poorly of SD, they can skip it. If they like SD, they can sort out how they want to persue updating a standard SD boot configuration, and given it's a standard one, they will require the least amount of documentation in order to do just that.
Say that somebody doesn't want files written to that SD card. They want RAW data. If a partition is in use, no brainer. They can do what they will with the rest of the card. When it's mounted in a PC, it shows as just blank media.
That's every bit as valid as "just drag and drop file here" is.
A partition does both equally well. Poking around in the MBR doesn't.
This new version combines the shortcut in the MBR (or what else is at sector 0) with the sectorwise searching for a signature at the begin of a boot-file. It does work here with SD cards (<=2GB) , and SDHC cards (>= 4GB).
For a bootable SD card you copy the bootfile to the fresh formated SD card - that was it.
Then the bootloader finds no shortcut in the MBR so it searches up to sector 19000 for a sector with the signature. This takes several seconds.
So if you want it faster use a (Spin)- Utility to write the shortcut, and now it boots in a few ms.
You can overwrte the boot file everytime with new code if it fits in the already allocated clusters. If you want disable booting you need to overwrite it with a file with wrong signature, just deleting will not help.
I have changed the place of the MBR shortcut a bit, so I have also attached the new utility.
' Minimal SD booter Test ' ---------------------- ' by Andy Schenk, Insonix con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 do = 8 'sd pins clk = 9 di = 10 cs = 11 obj dbg: "FullDuplexSerial" pub Main : i | tm ' ' This Spin code is not part of the boot code, it ' just starts the PASM cog and shows the result ' waitcnt(clkfreq*3+cnt) dbg.start(31,30,0,115200) cognew(@entry, 0) dbg.str(string("searching file...",13)) tm := cnt repeat until (i := long[$7000-4]) if i < 0 dbg.str(string("booting failed: ")) dbg.dec(i) if i== -10 dbg.str(string(13,"(no boot file)")) if i== -13 dbg.str(string(13,"(timeout SD access)")) else dbg.str(string("found at sector: ")) dbg.dec(i) dbg.str(string(" in ms:")) dbg.dec((cnt-tm)/(clkfreq/1000)) dbg.tx(13) byte[$707F] := 0 'show first 127 chars dbg.str($7000) repeat dat org entry ' set up mov blocksh,#0 or outa,clkmask mov dira,outmask 'pins neg phsb,#1 mov ctr2,onek '1000 x High for init oneloop call #sendiohi djnz ctr2,#oneloop mov starttime,cnt mov ctr2,#9 'try a few times reslp mov cmdo,#0 mov cmdp,#0 call #cmd cmp accb,#1 wz if_z jmp #tsthc djnz ctr2,#reslp tsthc mov cmdo,#8 'test if SD2 mov cmdp,#$1AA call #cmd cmp accb,#1 wz if_nz jmp #resok '< no mov ctr,#32 call #sendiocnt 'read volt inilp mov cmdo,#55 mov cmdp,#0 call #cmd mov cmdo,#41 mov cmdp,bit30 call #cmd cmp accb,#0 wz if_nz jmp #inilp mov cmdo,#58 'test if SDHC mov cmdp,#0 call #cmd mov ctr,#32 call #sendiocnt or outa,csmask test accb,bit30 wz if_z mov blocksh,#9 jmp #begin resok or outa,csmask call #sendiohi initloop mov cmdo,#55 call #cmd mov cmdo,#41 call #cmd cmp accb,#1 wz if_z jmp #initloop mov blocksh,#9 '0=SDHC 9=SD ' search signature and startsector in sector 0 begin mov blocknr,#0 mov bufad,hubbuf call #rblock 'read sector 0 mov bufad,hubbuf add bufad,#400 rdlong accb,bufad 'boot signature at 400 ? cmp accb,signatur0 wz if_nz jmp #search 'no signature: search sector add bufad,#4 rdlong blocknr,bufad 'read boot startsector at 404 ' search sector with boot file signature search mov bufad,hubbuf call #rblock rdlong accb,hubbuf cmp accb,signaturFile wz if_z jmp #found add blocknr,#1 cmp blocknr,lastblock wc if_b jmp #search neg accb,#10 'not found error: -10 fback sub hubbuf,#4 wrlong accb,hubbuf halt jmp #halt found mov lastblock,#3 'load boot code (only 3 sectors here) :load call #rblock djnz lastblock,#:load mov accb,blocknr jmp #fback 'okay rblock mov ctr2,sectorsz 'read block mov starttime,cnt mov cmdo,#17 mov cmdp,blocknr call #cmd call #readresp rbyte mov accb,#8 andn outa,clkmask or outa,clkmask test domask,ina wc addx acca,acca djnz accb,#rbyte+1 wrbyte acca,bufad add bufad,#1 djnz ctr2,#rbyte call #sendiohi call #sendiohi or outa,csmask rblock_ret ret sendio rol phsb,#24 'SPI routines sendiohi mov ctr,#8 sendiocnt mov accb,#0 bit andn outa,clkmask rol phsb,#1 wc muxc outa,dimask or outa,clkmask test domask,ina wc addx accb,accb djnz ctr,#bit sendio_ret sendiohi_ret sendiocnt_ret ret checktime mov duration,cnt sub duration,starttime cmp duration,clockfreq wc checktime_ret if_c ret neg accb,#13 'timeout error: -13 jmp #fback cmd cmp cmdo,#41 wz if_z or outa,csmask nop andn outa,csmask neg phsb,#1 call #sendiohi mov phsb,cmdo add phsb,#$40 call #sendio mov phsb,cmdp shl phsb,blocksh call #sendiohi call #sendiohi call #sendiohi call #sendiohi cmp cmdo,#8 wz if_z mov phsb,#$87 if_nz mov phsb,#$95 call #sendio cmp cmdo,#12 wz if_z neg phsb,#1 if_z call #sendiohi readresp neg phsb,#1 call #sendiohi call #checktime cmp accb,#$ff wz if_z jmp #readresp cmd_ret readresp_ret ret clockfreq long 80_000_000 onek long 1000 sectorsz long 512 bit30 long 1<<30 domask long 1<<do csmask long 1<<cs clkmask long 1<<clk dimask long 1<<di outmask long 1<<clk | 1<<di | 1<<cs lastblock long 19000 signatur0 byte "BOOT" signaturFile byte "P2BO" hubbuf long $7000 acca res 1 accb res 1 cmdo res 1 cmdp res 1 ctr res 1 ctr2 res 1 starttime res 1 duration res 1 bufad res 1 blocknr res 1 blocksh res 1AndyEdit: removed the copyright. The code is based on the FSRW driver from rokicki and lonesock, but havy modified and portet to PASM by me.
I like the idea of supporting partitionless booting. Very cool.
That look promising.
Are you meaning having two partitions? One for large raw boot image and the other, as filesystem, just for remaining spare space? Or something else?
If only for a large boot image then extending the FAT partition's reserved space can do it cleanly.
I've just realised what the kludge is with this approach. Someone not aware of how this file is being used might make the mistake of messing with it as a standard file. I guess, if it's marked as system file that might reduce this risk.
EDIT: Of course, this technicality doesn't affect the ROM code. It's doesn't care where the blocks are.
Can we first get a consensus of what the MBR shall be modified to???
1. Offset for parameter(s)? I have chosen $180. Andy has chosen 400decimal. My preference is a hex value. I am also happy with $100 which also seems to be fine. Thoughts???
2. The identifier? I agree that 1 long is probably sufficient. So let us on what that long shall be??? Any suggestions??? "P2x"+$0 (i.e. a string?) or a hex value???
3. The pointer? a long to the first boot code sector??? Do we require a second sector pointer or just use the first +1. From what I understand has been said, the Flash uses 1024 bytes initially, so we should conform to this.
4. If we add Andy's search if this fails, what should the search string/long/whatever be???
If we can at least agree with this then we can interchange each others code to test without having to re-write the MBR each time.
Maybe you need 3 sectors. The first has the 'long' identifier and the next 2 have the 1024 bytes we need to boot. While I am sure we could get away with 1020 bytes we would then have to remove the 4 bytes and substitute with zeros. Maybe just make the identifier with zeros. Your thoughts??? But then we have to play with the compiler output file. Not as simple as just copying a file to whatever file system is on the SD card.
I think the scan should be a fallback if the MBR pointer is not found.
I want to ensure that the sdspiFemto.spin pasm code that I use has the same SD commands because this is quite a proven set of code. I have been looking at your asm code to see the order of commands you issue to the SD card.
We will need to ensure that the P2 pasm driver code (implementing the SPI commands and sector reads) is not too fast for the SD cards. It is only a boot so it can be slower. We can use the NOP #n instruction nicely
2: I suppose the identifier, representing binary code booting, does need to be Propeller variant dependant.
3: A single pointer is good. Yep, loading a few consecutive blocks with it shouldn't be an issue.
4: Can't say I like the search idea. If the boot code isn't in the right place it's prolly messed up.
I think the details (signature, position) must be defined by Parallax / Chip, if it ever gets implemented.
I don't get your point 3. If you have the file found you can read a lot of sectors, they are all contiguous if written after formating, or minimally contiguous up to the cluster size if written later.
As I said before: this code is not meant as the final solution, just to show that it is possible to fit an SD bootloader in the remaining ROM space.
@evanh
The idea for the searching is that you don't need any tools on the PC, and can boot from a SD card without a Spin IDE, a PropPlug or such things.
If the bootcode writes the shortcut to itself automatic, then only the first boot takes a long time.
Andy
fsrwsdspiFemto_rr005e.spin
While I am certainly capable of writing the SPI code for the SD card, I haven't bothered because it was already done for me. I use this code currently so I am confident it works quite well. All that is required is to strip the eeprom code to see what it is really doing. We can add some extra possible code such as Andy has (SDHC cards etc if it's not there now) but I don't want to break what has already been done without a very good reason.
In other words, while it may be easier to start afresh, there is more risk. I am not prepared to put my name to that risk, and I presume Chip/Parallax will not be prepared either. It must be failsafe, so each extension must be built upon the failure of the previous sequence.
Bad to assume that without tool to ensure it. What's more that file would need careful maintenance on updates to ensure continued integrity. ... Which leads to the flaw in searching.
DOS --- ALWAYS need freshly formated DISK to be made it bootable.
That appears to all other OS systems to
Simple !!!
The very good reason is that fsrwFemto not supports SDHC cards, and it will be hard to strip this code down to the needed size.
To find an initialization code that works with many SD and SDHC cards and is short enough is the actual challenge for the ROM bootcode (as Kye has said so many times).
IAn SD bootcode that not supports SDHC cards is of no use. It's hard to find SD cards <= 2GB today. In a few years when the Prop2 comes
Andy
Yes, tools to ensure correct layout. Which is what we need also.
Plus I believe DOS had an INIT.EXE command for refreshing the partition boot data independent of the MBR - which was managed by FDISK.EXE. Both commands allowed for modifying without destroying the partition contents.
SYS.com / exe --- to transfer entire system to Flopy
You said That Chip will use PARTITION table info for boot.
That is not alway true on SD.----
As You can see from attached pictures ---- My SD that is 2BG and bootable with NT not have in Partition entries any values.
--- Most of BOOT sector have empty space but still You can see on left side of picture that it have all needed files to boot NT
So it is most safe to calculate them LOOK on
> "Boot Sector FAT.jpg"
It is values that needs to find it.
Functions in ROM should be really reliable and predictable things. At this point, having an EEPROM/FLASH for $0.50 isn't a big deal if it has an SD loader in it. At this point, I think I'd rather have the RAM back or a monitor application.
Very interesting conversation of how to do this in so little memory though...
Here's quick question in another direction altogether. Some mention has been made about FFTs on the current Prop which I am not interested in for this purpose but I am interested in knowing how well an FFT could perform on the Prop II in the audio spectrum. Could P2 be used in place of a DSP for equalizing and compression etc. Any ideas?
Absolutely! There is a specific MAC instruction, and supporting 64 bit accumulator. It'll fly
EDIT: Make that accumulators, plural, there is two. And a bunch of special instructions for manipulating them. This multiplier is separate from the general purpose one it seems. It's single cycle and takes 24 bit input with results always going to one of the special accumulators.
EDIT2: Or maybe the full multiple instruction loops on the 24 bit multiplier to get the extra bits.
Yep, Cluso pointed out that's why the pointer, and ID, go deep inside the first block, so it won't overwrite any FAT parameters if it's partitionless.