It occurs to me that, since the RAM/ROM only has 17 bits of address, it will be repeated over the 32-bit address range. So, RAM will grow up from 0, and ROM will grow down from %FFFFFFFF. It just so happens that they're both mirrored every 128K as well.
Interesting observation, Chip confirmed exactly that in #762 above.
It could make finding a Limits/RomSize.RamTOP entry easier, just read %FFFFFFFF ?
I have made some tests for a minimal SD card boot code. The attached zip includes two boot codes in PASM which both need ~152 longs.
Both implements only the SD card initialization and a sector read command, no FAT handling. They follow two different strategies to find the boot file:
The first version searches for a signature at begin of the boot file: "P2BOOT". Create a text file with the text P2BOOT at the begin of the first line (and then some welcome message on the following lines), and store it to the SD card with the name "boot.txt" (the name does not really matter for this first version, but for the second version). The SD card should be fresh formated, so that the file is at the lowest possible sector number.
The problem with this startegy is that the search takes a lot of time depending on the size of the FATs, and the root directory which came first on a SD card. The FAT size can vary in a wide range depending on the capacity of the SD card and the cluster size. I found the startsector of the first file between sector 280 on a 1 GB card with 32kB clusters, and 15200 on a 4GB card with 4kB clusters.
If you set your SD card pins and clockfreq in the spin code: "sd_boot_with_search.spin" and start it, you should get the text you have written to the file on the PST (Parallax Serial Terminal). The code searches up to sector 19000 (can be changed) but it takes around 10 seconds to find a file with such high sector numbers.
So I tried the way suggested by clusso and others also:
The second version needs a utility program (also privided in the ZIP), which writes the sector number of the boot file together with a signature into sector zero of the SD card at a safe place. Sector 0 can be a FAT16 or FAT32 bootsector or a MBR (Master Boot Record) for cards with partitions. All this sectors contain some i386 code which was used back in the MS-DOS days, but is unsused today (would be much too dangerous to execute an unknown code from an SD card for a PC at boot up). I have chosen location 440 for the signature long and 444 for the sector number, this should not overwrite important parameters on all three sector 0 versions.
If you set the clkfreq and SD pins in the sd_utility spin code and start it you can write and delete such a signature in sector 0 (and also generate the boot file if you not have done this already).
Then with the "sd_boot_with_signature.spin" you can test if it finds the boot file and prints the text on the Terminal. With this methode the file is found very quickly, and can be everywhere on the SD card.
For sure a real booter loads a binary and not a text file, but his is only a test if the file will be found. And if the SD card initialization works for many cards. I have one older 1GB card which not works, but ~10 newer cards which do work.
TRY THIS ONLY ON A SD CARD WHICH CONTAINS NO IMPORTANT FILES, AND WHICH YOU CAN FORMAT NEW IF IT FAILS.
The boot PASM code is not so nice formated and commented, I had not the time to do that. It uses PHSB as a output shift register, which is a relict of a counter driven SPI code, that I first used, but then changed to bit banged, because of code size.
So I think it is possible to boot from SD with only 660 bytes free ROM space, even with Prop 1 PASM.
I'm late to the party here, but watching with interest.
I think SD boot is well worth pursuing, I have prop based equipment in far flung places (eg beautiful south pacific islands) - and being able to mail out SD cards as a last resort potentially sales thousands of dollars each time. Yes we have cellphone sim cards to do remote updates, but already one sim provider went bust. At least all we had to do is mail out new data sim cards on that occasion.
Chip nailed it when mentioning having the complete personality being able to defined by a single plug in card removes more than 1 layer of complexity (flash and serial link).
Having attended one Raspberry Jam, I think we're seeing the beginnings of a revolution which will kill the serial tether, because the "target" will have enough capability (dev tools, internet connectivity) to develop comfortably on-device. From what I have see so far SD cards are freely swapped about, cloned, built upon, with remaining latest software components pulled down from the net. I see prop 2 as having similar ability (with suitable net communications).
I'd like to raise one issue I haven't seen much attention given to - it would be a disaster to have infringing code masked onto the prop 2's rom. Loading SD image in SPI mode seems safe enough, but this should be checked out. While I would love a mass storage emulation (I have tried same thing with a PIC), its potentially more dangerous given usb licensing.
I like the simplicity of your proposal - but could the two methods be combined?
So if there is a "shortcut" loaded into the MBR, this is used to quickly find the boot code. But if not it just slowly grinds through the sectors until the correct header is found indicating code.
That way those that don't want to mess with the MBR can leave it alone (at possible expense of speed unless they have a blank, new SD card), but still get a good result
Re the 7 instruction loop - prop 2's faster clock and single cycle instructions would certainly help
I like the simplicity of your proposal - but could the two methods be combined?
So if there is a "shortcut" loaded into the MBR, this is used to quickly find the boot code. But if not it just slowly grinds through the sectors until the correct header is found indicating code.
That way those that don't want to mess with the MBR can leave it alone (at possible expense of speed unless they have a blank, new SD card), but still get a good result
Re the 7 instruction loop - prop 2's faster clock and single cycle instructions would certainly help
Yes a comination of both would be the best, but need a bit more code space (~12 instructions).
Also with a bootime of several seconds it can be useful. For example to write another boot code into the flash, without a PropPlug.
The Prop2 runs with 20 MHz at boot up, thats the same speed as the Prop1 with 80 MHz (as in my tests). But the code will be shorter I guess.
It may also be possible to read ony the first 16 bytes of a sector, instead the full 512, to check the signature. I don't tried that.
I'd hate to imagine Prop2 revisions with more than 2kbytes of ROM. Either way, revision detect can be done just by reading known unique ROM code.
Bill Gates also hated to imagine anything over 640K once...
This is the opposite problem. The Prop2 design is locked into stealing from RAM space. Growing the ROM even as a reusable library is a rubbish idea.
As for the location of ROM, I'm no expert. I don't like the idea of separated ID's and pointers sitting in the first addresses though.
PS: Business men always say what will bring in the money. They have little regard for the truth. It was obvious the day it was said he was telling porkies. What I would have agreed with, at the time, is someone saying 4GB is enough.
I think Chip was just trying to keep the addressing minimal.
Placing ROM into RAM cells, also has many technical and business advantages
* It allows faster overall operation, as there is no ROM/RAM mux decision pathway
* they can use a std compiled RAM FAB block,
* It is (usually) a top-metal, late design decision, and the SIZE of ROM chosen is highly granular.
* Doing this is also fairly revision and speed safe.
(the disadvantage is above some size threshold, it consumes more silicon)
So it is the right choice for small ROMs
Potential issue with scanning for boot code on SD is that even though the user may have deleted or overwritten it, the actual content may still reside on the disk. So it's possible that the wrong or corrupted code may be booted. The only way to make sure all previous boot files have been removed is by doing a COMPLETE reformat on the partition you store the code in each time it needs to be updated. It may not be a huge deal, but it's unfortunately not as simple as just dragging and dropping newer code. A possible solution is to make SD boot code the exact size of the partition, so that the previous file is always completely overwritten when replaced. My understanding is that the minimum FAT16 partition size is just slightly over 4MB, though FAT12 can be as low as 1.5k, so that may be an option.
I have made some tests for a minimal SD card boot code. The attached zip includes two boot codes in PASM which both need ~152 longs.
Both implements only the SD card initialization and a sector read command, no FAT handling. They follow two different strategies to find the boot file:
The first version searches for a signature at begin of the boot file: "P2BOOT". Create a text file with the text P2BOOT at the begin of the first line (and then some welcome message on the following lines), and store it to the SD card with the name "boot.txt" (the name does not really matter for this first version, but for the second version). The SD card should be fresh formated, so that the file is at the lowest possible sector number.
Placing ROM into RAM cells, also has many technical and business advantages
* It allows faster overall operation, as there is no ROM/RAM mux decision pathway
I'm not sure I understand this point. From my classes on the subject (look, book learning!), I don't see what would make a section of RAM any different from a section of ROM, except for the bit level. But, once that is abstracted out then the addressing and the data I/O can be exactly the same. The ROM and RAM can share the same address space (assuming there is enough address lines, of course) with no distinction, or even awareness, necessary in the code.
I understand for the current Prop 2 that's not the case, that the ROM cells are effectively hard wired RAM cells, but I'm questioning the second phrase of your first point.
Traditionally RAM and ROM were different devices on a memory bus. One used the low order address bits were connected directly to the devices to select the required memory location. High order address bit were decode to produce chip select signals that would enable either the RAM or the ROM or whatever other devices were on the bus.
It is that decoding of the high order address bits into separate chip elect signals that introduces extra delays into the memory access.
This argument probably applies equally as well when the RAM, ROM and other devices are integrated onto the same chip. The same logic has to exist somewhere all be it much faster now as it is smaller and "closer to the action".
However it seems that in the Prop HUB, the memory cells are all in one address space except that each cell can be configured as read/write or just read only. The configuration being done by some "simple" mask process. In this way the decoding logic described above is not required and no extra delays are introduced.
Placing ROM into RAM cells, also has many technical and business advantages
* It allows faster overall operation, as there is no ROM/RAM mux decision pathway
That one needs clarified. I know it's not what Heater said. I suspect it's just a space saving which is why your next point works.
* they can use a std compiled RAM FAB block,
Well, I'd consider this a disadvantage in most cases given the size of SRAM cells.
* It is (usually) a top-metal, late design decision, and the SIZE of ROM chosen is highly granular.
* Doing this is also fairly revision and speed safe.
I don't see how a separate ROM couldn't easily be resized/remapped. Ie: I'm not seeing any advantage here.
(the disadvantage is above some size threshold, it consumes more silicon)
So it is the right choice for small ROMs
Thanks Ariba for your input. Unfortunately havent had time to check the code - just enough to read through the thread - I have been offline for 1 1/2 days (since my last post). David Betz also PM'd me.
This is what I propose...
On the MBR (sector #0):-
At offset $180 (so it does not encroach on the partition tables that may be at the end, and does not interfere with the parameters at the beginning) we store
11 bytes of identification followed by $00 (so it could be a string), followed by a long that stores the sector location of the boot data sectors.
The boot data sectors will most probably be located in a file, but we are going to point the MBR just at the start of the data. The length of the first boot will be the same as the FLASH (1024 bytes???). Other data sectors may follow at the discretion of the boot code.
This makes the ROM code quite simple. It knows nothing about the format of the SD card which means that it should be able to support all the existing formats and any new formats that come along.
On my SD card that was formatted under Windows XP, the MBR was mostly 0's except for what may be the partition table near the end. So I just used my prop program to locate my boot file and determined it's sector. I then wrote this sector number plus the text "ParallaxII" $00 onto my MBR (I used an offset of $1FE before I realised that this was within the Partition area. So my code posted last can locate this and boot my PropOS (which can do DIR, and even launch and run ZiCog). So I am doing real testing.
AsI explained offline to David, I am extremely busy until 1 September, so I am trying to steal away some time to continue the code. For anyone willing to help, I need that code (beause I am confident that it works reliably with most SD cards (I am not aware of any that dont work although I do recommend SanDisk). I need to determine the sequence of commands sent to the SD card and the responses returned. Then this can be coded in pasm for the P2.
I also need to re-do the low level SPI pasm code in P2 (to replace the pasm driver). This should be quite simple.
Two parts are required...
1. Isue commands to the SD card and receive SD responses
2. Issue the read sector command with the sector, and read the 512 byte sector returned.
I'm guessing the "mux" part is bus merging between the two blocks. Usually done as tri-stating buffers. There is an implicit suggestion that the existing design doesn't have any but that doesn't quite gel either.
Address decode happens everywhere ... makes no difference what the memory type or device function is.
Address decode does happen everywhere. It's just that back in the day of EPROMs and static RAM chips you would often see something like a 3 to 8 line decoder chip selecting devices which was for sure an extra delay to take into account.
MUXing of memory blocks would add delay.
But, if I understand correctly is that what we have in the Prop is a sea of memory cells that can be made RAM or ROM, no change to the surrounding selection or muxing logic, just mask the cell differently.
SECURITY
I was thinking that it might be a possible weakness to allow downloading ability permitting brute force attacks.
I wonder if it might be prudent (since we have a number of user fuses) to identify 3 fuses, one each for Serial, Flash and SD. If the individual fuse was blown then that boot ability would be blocked. i.e. if the Serial fuse bit was blown, then serial downloading would not be possible. If all 3 fuses were blown then perhaps the Flash only should be allowed.
Any thoughts???
... i.e. if the Serial fuse bit was blown, then serial downloading would not be possible. If all 3 fuses were blown then perhaps the Flash only should be allowed.
There is some interest in this but not for security, rather improving pin-count instead. Security is pretty beefy with the encryption.
... we store 11 bytes of identification followed by $00 (so it could be a string), followed by a long that stores the sector location of the boot data sectors.
The boot data sectors will most probably be located in a file, but we are going to point the MBR just at the start of the data. The length of the first boot will be the same as the FLASH (1024 bytes???). Other data sectors may follow at the discretion of the boot code.
Given how small you are talking - 1024 bytes, I'm thinking just boot the MBR instead. Let the code in the MBR do the dirty work, that's what it's purpose is. Obviously still isn't enough for filesystem support but would be enough to continue on as you've just outlined.
But, if I understand correctly is that what we have in the Prop is a sea of memory cells that can be made RAM or ROM, no change to the surrounding selection or muxing logic, just mask the cell differently.
They always need muxed at some level, just simply from one cell to the next in the RAM array for example. That's the nature of general buses.
... something like a 3 to 8 line decoder chip selecting devices which was for sure an extra delay to take into account.
Very small delays, completely asynchronous. And remember this is all happening inside the one piece of silicon where there is no massive driver stages for hauling on a pin. The biggest delays are likely the trace lengths getting from one side of the chip to the other.
To emphasise my earlier point on it happens everywhere, an independent RAM block sees the same delays, albeit through a different decoder, as a ROM block would see.
For initiate BOOT SD.
1. Newly formated SD
2. Save BOOT file as first one in DIR entry ----> To be continuous
As Cluster have 64x512 Bytes = 32_768 BYTES guaranteed Continuous ( smallest BOOT file that are guaranteed to be in continuous on SD )
For BOOT:
1. Read first 28H bytes of BOOT sector to CLUT. (Maybe test if it have data and not is 000000) -- Formated it always need have EB 00 90 Hex and after MSDOS -- signature
2. from table -- calculate start position of DIR.
3. Read first entry of DIR and find first FAT position ( IT have pointer to first cluster of file ) of BOOT file xxxxxxxx.xxx.
4. Read that file -- ( for security that file need checksum) load to HUB --- Test checksum and if OKI ---> RUN
5. DONE
Given how small you are talking - 1024 bytes, I'm thinking just boot the MBR instead. Let the code in the MBR do the dirty work, that's what it's purpose is. Obviously still isn't enough for filesystem support but would be enough to continue on as you've just outlined.
Having said all that, Heater, you aren't wrong, the delays do add up. The bigger everything is the longer it takes. An adder for example, the wider the word size is, the more logic is needed and the slower it goes to perform a simple add.
So, the more addresses there are, the bigger and slower the decoders become.
1. Newly formated SD
2. Save BOOT file as first one in DIR entry ----> To be continuous
As Cluster have 64x512 Bytes = 32_768 BYTES guaranteed Continuous ( smallest BOOT file that are guaranteed to be in continuous on SD )
I'm looking at 4kB clusters on one I've just poked in here. No guarantee of 32kB clusters. And you've just added a bunch of work formatting the SD card. I'd rather not have to refill the card's content every time there is an exe update.
2. from table -- calculate start position of DIR.
MBR only has partition entries in it's table. Need another round of reading to get to FAT32 partition. Then there is the assumption of first file, then the assumption of contiguous blocks. Many complications. Best leave that to the loaded boot code.
Keep the ROM code minimal.
I'm thinking there is going to be a tool, maybe integrated as well, for fixing the boot image in consecutive blocks and also writing the MBR with whatever it needs.
EDIT: That's right, I remember now, the default minimum cluster size for FAT32 is 4kB.
I got a better way than a special partition or even a contiguous file. BTW, every option so far has needed privileged block (sector) level access to initialise the SD card from the development tools.
Okay, just been reading about FAT partitions on Wikipedia and, not surprisingly, there is preallocated reserved space at the start of the FAT partition. The default reserved size is 32 blocks (16 kB). Within this, blocks 0,1 and 6 are used for basic FAT32 structures. The rest are never used unless there is an OS booting from that partition. Funnily, that's exactly what we're doing.
So, without too much extra effort, the MBR could be skipped altogether in terms of poking data onto the SD card. And 14.5kB should be enough to do a decent boot from. The one assumption is that the SD card is formatted with one FAT32 partition, ie: how they are purchased.
f you have enough code space, all the various suggested scanning off the SD boot sector parameters are doable.
But it has to fit in about 160 longs, and you all seem to have no idea of how tight this is. The needed code for initialization of the card, the SPI routines and read sector code together takes 80% of the available memory. Only very few instructions left to check all the possible formating variations. (FAT16, FAT32 with/without MBR, cluster size, number of FATs on so on).
So either you dictate how exactly the SD card must be formated, or you implement a strategy to find the boot file without all the FAT-boot-parameter stuff.
Another simple way would be to provide a disk image that contains the boot file. The utility to write such images exist on all platforms. This concept is also used by the Raspberry PI for example. The nice thing: You know exactly the structure of the sectors, and all you have to do is to check a signature at a certain sector and boot from this sector if the signature is valid.
Andy
Edit: What really counts for me is that SD booting is doable in the available ROM code space. How exactly it will be implemented depends on how many instructions you have left to find the file.
So either you dictate how exactly the SD card must be formated, or you implement a strategy to find the boot file without all the FAT-boot-parameter stuff.
Another simple way would be to provide a disk image that contains the boot file. The utility to write such images exist on all platforms. This concept is also used by the Raspberry PI for example. The nice thing: You know exactly the structure of the sectors, and all you have to do is to check a signature at a certain sector and boot from this sector if the signature is valid.
That's interesting. So the RaspberryPi can't parse the FAT filesystem from it's boot ROM? It just loads a second stage bootloader from some known location on the SD card? That certainly simplifies things!
Comments
Interesting observation, Chip confirmed exactly that in #762 above.
It could make finding a Limits/RomSize.RamTOP entry easier, just read %FFFFFFFF ?
Both implements only the SD card initialization and a sector read command, no FAT handling. They follow two different strategies to find the boot file:
The first version searches for a signature at begin of the boot file: "P2BOOT". Create a text file with the text P2BOOT at the begin of the first line (and then some welcome message on the following lines), and store it to the SD card with the name "boot.txt" (the name does not really matter for this first version, but for the second version). The SD card should be fresh formated, so that the file is at the lowest possible sector number.
The problem with this startegy is that the search takes a lot of time depending on the size of the FATs, and the root directory which came first on a SD card. The FAT size can vary in a wide range depending on the capacity of the SD card and the cluster size. I found the startsector of the first file between sector 280 on a 1 GB card with 32kB clusters, and 15200 on a 4GB card with 4kB clusters.
If you set your SD card pins and clockfreq in the spin code: "sd_boot_with_search.spin" and start it, you should get the text you have written to the file on the PST (Parallax Serial Terminal). The code searches up to sector 19000 (can be changed) but it takes around 10 seconds to find a file with such high sector numbers.
So I tried the way suggested by clusso and others also:
The second version needs a utility program (also privided in the ZIP), which writes the sector number of the boot file together with a signature into sector zero of the SD card at a safe place. Sector 0 can be a FAT16 or FAT32 bootsector or a MBR (Master Boot Record) for cards with partitions. All this sectors contain some i386 code which was used back in the MS-DOS days, but is unsused today (would be much too dangerous to execute an unknown code from an SD card for a PC at boot up). I have chosen location 440 for the signature long and 444 for the sector number, this should not overwrite important parameters on all three sector 0 versions.
If you set the clkfreq and SD pins in the sd_utility spin code and start it you can write and delete such a signature in sector 0 (and also generate the boot file if you not have done this already).
Then with the "sd_boot_with_signature.spin" you can test if it finds the boot file and prints the text on the Terminal. With this methode the file is found very quickly, and can be everywhere on the SD card.
For sure a real booter loads a binary and not a text file, but his is only a test if the file will be found. And if the SD card initialization works for many cards. I have one older 1GB card which not works, but ~10 newer cards which do work.
TRY THIS ONLY ON A SD CARD WHICH CONTAINS NO IMPORTANT FILES, AND WHICH YOU CAN FORMAT NEW IF IT FAILS.
The boot PASM code is not so nice formated and commented, I had not the time to do that. It uses PHSB as a output shift register, which is a relict of a counter driven SPI code, that I first used, but then changed to bit banged, because of code size.
So I think it is possible to boot from SD with only 660 bytes free ROM space, even with Prop 1 PASM.
Andy
What is the appx SD Clock speed for these numbers ?
Andy
I think SD boot is well worth pursuing, I have prop based equipment in far flung places (eg beautiful south pacific islands) - and being able to mail out SD cards as a last resort potentially sales thousands of dollars each time. Yes we have cellphone sim cards to do remote updates, but already one sim provider went bust. At least all we had to do is mail out new data sim cards on that occasion.
Chip nailed it when mentioning having the complete personality being able to defined by a single plug in card removes more than 1 layer of complexity (flash and serial link).
Having attended one Raspberry Jam, I think we're seeing the beginnings of a revolution which will kill the serial tether, because the "target" will have enough capability (dev tools, internet connectivity) to develop comfortably on-device. From what I have see so far SD cards are freely swapped about, cloned, built upon, with remaining latest software components pulled down from the net. I see prop 2 as having similar ability (with suitable net communications).
I'd like to raise one issue I haven't seen much attention given to - it would be a disaster to have infringing code masked onto the prop 2's rom. Loading SD image in SPI mode seems safe enough, but this should be checked out. While I would love a mass storage emulation (I have tried same thing with a PIC), its potentially more dangerous given usb licensing.
I like the simplicity of your proposal - but could the two methods be combined?
So if there is a "shortcut" loaded into the MBR, this is used to quickly find the boot code. But if not it just slowly grinds through the sectors until the correct header is found indicating code.
That way those that don't want to mess with the MBR can leave it alone (at possible expense of speed unless they have a blank, new SD card), but still get a good result
Re the 7 instruction loop - prop 2's faster clock and single cycle instructions would certainly help
Yes a comination of both would be the best, but need a bit more code space (~12 instructions).
Also with a bootime of several seconds it can be useful. For example to write another boot code into the flash, without a PropPlug.
The Prop2 runs with 20 MHz at boot up, thats the same speed as the Prop1 with 80 MHz (as in my tests). But the code will be shorter I guess.
It may also be possible to read ony the first 16 bytes of a sector, instead the full 512, to check the signature. I don't tried that.
Andy
This is the opposite problem. The Prop2 design is locked into stealing from RAM space. Growing the ROM even as a reusable library is a rubbish idea.
As for the location of ROM, I'm no expert. I don't like the idea of separated ID's and pointers sitting in the first addresses though.
PS: Business men always say what will bring in the money. They have little regard for the truth. It was obvious the day it was said he was telling porkies. What I would have agreed with, at the time, is someone saying 4GB is enough.
Placing ROM into RAM cells, also has many technical and business advantages
* It allows faster overall operation, as there is no ROM/RAM mux decision pathway
* they can use a std compiled RAM FAB block,
* It is (usually) a top-metal, late design decision, and the SIZE of ROM chosen is highly granular.
* Doing this is also fairly revision and speed safe.
(the disadvantage is above some size threshold, it consumes more silicon)
So it is the right choice for small ROMs
In attachment You have entire info to find DIR position without scanning entire area
I'm not sure I understand this point. From my classes on the subject (look, book learning!), I don't see what would make a section of RAM any different from a section of ROM, except for the bit level. But, once that is abstracted out then the addressing and the data I/O can be exactly the same. The ROM and RAM can share the same address space (assuming there is enough address lines, of course) with no distinction, or even awareness, necessary in the code.
I understand for the current Prop 2 that's not the case, that the ROM cells are effectively hard wired RAM cells, but I'm questioning the second phrase of your first point.
Traditionally RAM and ROM were different devices on a memory bus. One used the low order address bits were connected directly to the devices to select the required memory location. High order address bit were decode to produce chip select signals that would enable either the RAM or the ROM or whatever other devices were on the bus.
It is that decoding of the high order address bits into separate chip elect signals that introduces extra delays into the memory access.
This argument probably applies equally as well when the RAM, ROM and other devices are integrated onto the same chip. The same logic has to exist somewhere all be it much faster now as it is smaller and "closer to the action".
However it seems that in the Prop HUB, the memory cells are all in one address space except that each cell can be configured as read/write or just read only. The configuration being done by some "simple" mask process. In this way the decoding logic described above is not required and no extra delays are introduced.
Well, I'd consider this a disadvantage in most cases given the size of SRAM cells.
I don't see how a separate ROM couldn't easily be resized/remapped. Ie: I'm not seeing any advantage here.
Reinforcing the 2k limit I guess.
How so? Where am I wrong?
This is what I propose...
On the MBR (sector #0):-
At offset $180 (so it does not encroach on the partition tables that may be at the end, and does not interfere with the parameters at the beginning) we store
11 bytes of identification followed by $00 (so it could be a string), followed by a long that stores the sector location of the boot data sectors.
The boot data sectors will most probably be located in a file, but we are going to point the MBR just at the start of the data. The length of the first boot will be the same as the FLASH (1024 bytes???). Other data sectors may follow at the discretion of the boot code.
This makes the ROM code quite simple. It knows nothing about the format of the SD card which means that it should be able to support all the existing formats and any new formats that come along.
On my SD card that was formatted under Windows XP, the MBR was mostly 0's except for what may be the partition table near the end. So I just used my prop program to locate my boot file and determined it's sector. I then wrote this sector number plus the text "ParallaxII" $00 onto my MBR (I used an offset of $1FE before I realised that this was within the Partition area. So my code posted last can locate this and boot my PropOS (which can do DIR, and even launch and run ZiCog). So I am doing real testing.
AsI explained offline to David, I am extremely busy until 1 September, so I am trying to steal away some time to continue the code. For anyone willing to help, I need that code (beause I am confident that it works reliably with most SD cards (I am not aware of any that dont work although I do recommend SanDisk). I need to determine the sequence of commands sent to the SD card and the responses returned. Then this can be coded in pasm for the P2.
I also need to re-do the low level SPI pasm code in P2 (to replace the pasm driver). This should be quite simple.
Two parts are required...
1. Isue commands to the SD card and receive SD responses
2. Issue the read sector command with the sector, and read the 512 byte sector returned.
I'm guessing the "mux" part is bus merging between the two blocks. Usually done as tri-stating buffers. There is an implicit suggestion that the existing design doesn't have any but that doesn't quite gel either.
Address decode happens everywhere ... makes no difference what the memory type or device function is.
And get my name right!
Oops sorry, your name duly corrected.
Address decode does happen everywhere. It's just that back in the day of EPROMs and static RAM chips you would often see something like a 3 to 8 line decoder chip selecting devices which was for sure an extra delay to take into account.
MUXing of memory blocks would add delay.
But, if I understand correctly is that what we have in the Prop is a sea of memory cells that can be made RAM or ROM, no change to the surrounding selection or muxing logic, just mask the cell differently.
I was thinking that it might be a possible weakness to allow downloading ability permitting brute force attacks.
I wonder if it might be prudent (since we have a number of user fuses) to identify 3 fuses, one each for Serial, Flash and SD. If the individual fuse was blown then that boot ability would be blocked. i.e. if the Serial fuse bit was blown, then serial downloading would not be possible. If all 3 fuses were blown then perhaps the Flash only should be allowed.
Any thoughts???
There is some interest in this but not for security, rather improving pin-count instead. Security is pretty beefy with the encryption.
Given how small you are talking - 1024 bytes, I'm thinking just boot the MBR instead. Let the code in the MBR do the dirty work, that's what it's purpose is. Obviously still isn't enough for filesystem support but would be enough to continue on as you've just outlined.
They always need muxed at some level, just simply from one cell to the next in the RAM array for example. That's the nature of general buses.
Very small delays, completely asynchronous. And remember this is all happening inside the one piece of silicon where there is no massive driver stages for hauling on a pin. The biggest delays are likely the trace lengths getting from one side of the chip to the other.
To emphasise my earlier point on it happens everywhere, an independent RAM block sees the same delays, albeit through a different decoder, as a ROM block would see.
Why that complicated?
Look on My previous post.
For initiate BOOT SD.
1. Newly formated SD
2. Save BOOT file as first one in DIR entry ----> To be continuous
As Cluster have 64x512 Bytes = 32_768 BYTES guaranteed Continuous ( smallest BOOT file that are guaranteed to be in continuous on SD )
For BOOT:
1. Read first 28H bytes of BOOT sector to CLUT. (Maybe test if it have data and not is 000000) -- Formated it always need have EB 00 90 Hex and after MSDOS -- signature
2. from table -- calculate start position of DIR.
3. Read first entry of DIR and find first FAT position ( IT have pointer to first cluster of file ) of BOOT file xxxxxxxx.xxx.
4. Read that file -- ( for security that file need checksum) load to HUB --- Test checksum and if OKI ---> RUN
5. DONE
So, the more addresses there are, the bigger and slower the decoders become.
MBR only has partition entries in it's table. Need another round of reading to get to FAT32 partition. Then there is the assumption of first file, then the assumption of contiguous blocks. Many complications. Best leave that to the loaded boot code.
Keep the ROM code minimal.
I'm thinking there is going to be a tool, maybe integrated as well, for fixing the boot image in consecutive blocks and also writing the MBR with whatever it needs.
EDIT: That's right, I remember now, the default minimum cluster size for FAT32 is 4kB.
Okay, just been reading about FAT partitions on Wikipedia and, not surprisingly, there is preallocated reserved space at the start of the FAT partition. The default reserved size is 32 blocks (16 kB). Within this, blocks 0,1 and 6 are used for basic FAT32 structures. The rest are never used unless there is an OS booting from that partition. Funnily, that's exactly what we're doing.
So, without too much extra effort, the MBR could be skipped altogether in terms of poking data onto the SD card. And 14.5kB should be enough to do a decent boot from. The one assumption is that the SD card is formatted with one FAT32 partition, ie: how they are purchased.
But it has to fit in about 160 longs, and you all seem to have no idea of how tight this is. The needed code for initialization of the card, the SPI routines and read sector code together takes 80% of the available memory. Only very few instructions left to check all the possible formating variations. (FAT16, FAT32 with/without MBR, cluster size, number of FATs on so on).
So either you dictate how exactly the SD card must be formated, or you implement a strategy to find the boot file without all the FAT-boot-parameter stuff.
Another simple way would be to provide a disk image that contains the boot file. The utility to write such images exist on all platforms. This concept is also used by the Raspberry PI for example. The nice thing: You know exactly the structure of the sectors, and all you have to do is to check a signature at a certain sector and boot from this sector if the signature is valid.
Andy
Edit: What really counts for me is that SD booting is doable in the available ROM code space. How exactly it will be implemented depends on how many instructions you have left to find the file.