I think the serial loader could be improved by allowing to set a start address in the data block to load. Like the device-id it could be 0 for a normal load, but one could set a start address if needed.
It is common for loaders to have the general form including Address,ByteCount and DataBlock
Intel hex has done that since Adam was a boy...
In serial streaming ones, often they also have a header-tag, so that exact alignment is less important. I think that has been suggested for simpler SD loaders to.
Actually, it goes way before micros, to minis and mainframes of at least the late 60's. But they didn't boot that way. The initial boot has been done from an initial block read, even from card decks.
But none of that has to be relevant to today's implementation.
However, if we get into another debate as how to do it, it won't make the silicon for 22nd.
well @cluso99 this rom-booter code needs to get changed to get your SD loader into the boot chain and TAQOZ also.
Adding a start address between the device-id and the data-part of the HEX or TXT loaders will not really need much code, neither on the P2 side nor for any external loader. just send 00000000 if you don't need multiple blocks or a different start address.
But this simple change would allow @peter and yourself to load code directly into the rom area at the end of the physical address-space without sending a HEX or BASE64 encoded text to send almost 4GB zeros and then your code.
Actual I got this idea while reading chips booter code. He just does it there. The first 4 lines just transfer a block into COG ram and a block into LUT ram.
It is somehow like ORGH in a SPIN2/PASM2 file, just for the serial loaders. Load this into the ROM area, load this at the end of ram and load this at the start of ram and run it.
The serial loader differs from flash, because flash just loads 2KB into COG 0 and runs it in COGexec, whereas the serial loader can load the complete HUB (except rom, arguable) and starts then in HUBexec.
So how is the SD connected in the current configuration and can we use one of those pins to check for pull up or not to distinguish between 'boot from sd, ignoring serial' and 'boot from sd, but give serial a chance'?
Is your sd boot code planned for loading into HUB like the serial loader or are you planning to just load a 2K chunk into the COG like the Flash one does?
And what pin would be available to signal that TAQOZ does not need to wait for serial boot loader to timeout before getting activated, reboot taking 60s is not so cool?
Yes, i think some pull-up or pull-down resistor is necessary to cue my loader to jump to Cluso's code. But, it may need to come back and attempt serial loading if SD fails. That's too complicated, actually. If I jump to Cluso's code, there's no coming back.
Why do you have both Cluso's and Peter's SD code? Since TAQOZ is by far the more flexible of the two (being a whole Forth implementation), why not rely on it exclusively for SD boot? That will allow you to significantly simplify the boot sequence and also save some ROM.
Why do you have both Cluso's and Peter's SD code? Since TAQOZ is by far the more flexible of the two (being a whole Forth implementation), why not rely on it exclusively for SD boot? That will allow you to significantly simplify the boot sequence and also save some ROM.
I tried to argue this a number of times but it fell on deaf ears.
Why do you have both Cluso's and Peter's SD code? Since TAQOZ is by far the more flexible of the two (being a whole Forth implementation), why not rely on it exclusively for SD boot? That will allow you to significantly simplify the boot sequence and also save some ROM.
I tried to argue this a number of times but it fell on deaf ears.
my impression following the discussions was that @Cluso99 and @Peter_Jakacki
would get together (at least virtually) to combine their efforts into one solution that will then be included.
Yes, Peter and I will combine the efforts. But it will not be implemented as you have described.
You have to understand what is going on behind the scenes. Peter has needed to change direction with what I forsee as quite a major shift because his code is now needing to run from high hub instead of bottom hub.
My code is designed to be raw SD boot code whereas Peter's is based on full FAT32. It's a requirement that my SD boot code be able to cater for any future changes in SD card specifications, as much as humanly possible. So that is where I concentrated. Peter concentrated on Tachyon, using his existing FAT32 model.
I need to chat to Chip to implement my SD boot code, but he is still busy. I now also have work commitments.
Peter and I have both tried to get code changes in the existing ROM so we could test our changes easily, but due to Chip's time, that didn't happen.
We have a finite window that is closing fast. I am here just waiting.
If you actually look at my SD boot source, you will see the MIT license attached. Its on all my published prop code (I do have unpublished copyrighted code for a commercial product).
You have to understand what is going on behind the scenes. Peter has needed to change direction with what I forsee as quite a major shift because his code is now needing to run from high hub instead of bottom hub.
Hmm... I've seen that hinted at - is that because taqoz used word tokens as absolute address pointers for speed, and those work better on LSB=0 addresses ?
Is it smarter to map the ROM to low base, of 00H then ?
I guess Debug needs to be Hi and isolated, and not get in the way of compact/fast user code ? - and boot naturally goes into same area as debug
Maybe P2 needed something to better support memory relocation ( to late to add now..)
Making it run in high memory is pretty easy really but testing it in high memory with an existing boot ROM that doesn't have any hooks in it for passing to TAQOZ and SD makes it harder to test. Even the Flash boot only loads 1kB which means that if I wanted to lock stuff in there to test at power-up then it would have to be a 1+2 stage boot at least. What I really need is to be able to load the boot ROM memory in much the same way the boot ROM is loaded now and then I could test it in situ so I know for certain that it will behave properly. If at least we had a P2 simulator I could test with that but alas the tools that we need now are tools that we will end up having once we do what we do before we have the tools we need.
Ideally I would like to be able to load my code into the FPGA itself alongside Chip's code but I do know why we can't do that. If though Chip's FPGA boot code (or a version) simply read in the boot ROM from SPI Flash if present (better still, something completely independent like an I2C EEPROM on totally separate I/O and loaded via a P1 for testing) and loaded that into high mem then all of us could test the boot ROM. Now what Chip has now should allow that I guess but I would have to write a signed loader that fits into 1kB that then loads the "boot ROM" over the default boot ROM. To test it properly however it needs to go through Chip's final silicon boot process and since we have control of this image we would have hooks for simple SD user code and TAQOZ either interactively or with FAT32 user code.
The important thing is to have a final "boot ROM image" that works with the FPGA exactly as it would in silicon. The independent I2C EEPROM on say P56 & P57 would allow that and I am used to loading I2C EEPROM externally for production purpose and I have "dongles" that do that. So the idea would be I could take Chip's final boot code, integrate Cluso's and my code with it, load it into the EEPROM and then Chip's FPGA version preboot code could load 16k of that EEPROM unchecked and as-is into the boot ROM in upper memory and then we can let it run, just like it would in the silicon version. Maybe I can do that now with Chip's code but I like the independent memory idea because it's a bit like those expensive development versions of mask ROM or OTP micros we used to play with that had a socket on top of the chip that allowed you run the final code in an external memory chip, the same way it would run when it was locked into mask ROM.
I may have missed some important points but I needed to verbalize this so I could get a better picture of what I needed to do next. Now it's off to study Chip's boot code properly.
Making it run in high memory is pretty easy really but testing it in high memory with an existing boot ROM that doesn't have any hooks in it for passing to TAQOZ and SD makes it harder to test. Even the Flash boot only loads 1kB
If Chip's loader read a Address,Size header, would that speed things enough ?
The important thing is to have a final "boot ROM image" that works with the FPGA exactly as it would in silicon.
Ideally yes, but it will be hard to match that exactly as, the Verilog must differ somewhere to load the internal ROM, vs external pins.
That does mean that piece of code needs very careful visual checking and simulating
The independent I2C EEPROM on say P56 & P57 would allow that and I am used to loading I2C EEPROM externally for production purpose and I have "dongles" that do that. So the idea would be I could take Chip's final boot code, integrate Cluso's and my code with it, load it into the EEPROM and then Chip's FPGA version preboot code could load 16k of that EEPROM unchecked and as-is into the boot ROM in upper memory and then we can let it run, just like it would in the silicon version.
Interesting, not sure how much effort adding that is ? Certainly it's some verilog and testing time.
I did notice newer SPI parts have what is called fast-boot.
That allows a simple RST-CS-CLOCK sequence, which has to be getting very close to the ROM case ? (No address emitted, just a few dummy clocks)
Maybe Chip could map (RST).CS.SCK to 3 pins, for a part that is pre-configured to fast-boot ? You would need to externally load the SPI - can your "dongles" manage SPI ?
I'll check which Winbond parts support fast-boot...
Ideally yes, but it will be hard to match that exactly as, the Verilog must differ somewhere to load the internal ROM, vs external pins.
That does mean that piece of code needs very careful visual checking and simulating
Interesting, not sure how much effort adding that is ? Certainly it's some verilog and testing time.
Well the serial ROM in Verilog shouldn't be affecting any critical timing paths IMO. So the special FPGA dev version of a bootloader would not have to worry about anything else but loading an independent memory device on independent pins and I2C is just about as simple as it gets, we all know how they work and it only has to load the first 16kB of the EEPROM which sequentially at 1MHz (it doesn't matter if it assumes and uses the crystal) or so would take around 150ms although we are not that concerned about this boot time except of course in terms of Chip's serial boot but that can be handled a variety of ways. I use a small P1 board as a dongle, so I just send it a file, normally hex but other formats are easy to adapt, and then this loads it into the EEPROM directly while holding the P2 reset active. Once it releases it then the dev version preboot ROM in the FPGA simply loads in 16kB into $FC000 and runs it.
This way we can say with a high degree of confidence that the boot ROM will work as we expect it to since we have verified it to be so. I don't know if it is at all possible for that final 16kB boot image to be worked into the Verilog so that everybody could test it.
Well the serial ROM in Verilog shouldn't be affecting any critical timing paths IMO. So the special FPGA dev version of a bootloader would not have to worry about anything else but loading an independent memory device on independent pins and I2C is just about as simple as it gets, we all know how they work and it only has to load the first 16kB of the EEPROM which sequentially at 1MHz (it doesn't matter if it assumes and uses the crystal) or so would take around 150ms although we are not that concerned about this boot time except of course in terms of Chip's serial boot but that can be handled a variety of ways. I use a small P1 board as a dongle, so I just send it a file, normally hex but other formats are easy to adapt, and then this loads it into the EEPROM directly while holding the P2 reset active. Once it releases it then the dev version preboot ROM in the FPGA simply loads in 16kB into $FC000 and runs it.
i2c is slow, and more complex to patch into Verilog, and is not quite the same as Serial ROM. Best to try and get as close to P2 as possible with external memory ?
A SPI-MCU in slave mode is another choice, but I think more work than a fast-boot mode SPI part.
Can your 'dongles' handle SPI parts ?
I find the MX25L12835FMI-10G as a stocked part, that has the fast-boot mode (just clock after reset), it can clock at 70~133MHz and takes a user choice of 7/9/11/13 clocks to issue data.
A header tag could easily auto-align, or an offset counter done.
That's a 16 pin part, so has the separate RST pin, and the same part allows QuadSPI testing - ie connect 2, one for user-code image, and one for the 'boot image in a corner'
Actually multiple boot images can be compared, via the Non Volatile FBR, 31 to 4 set the BOOT address. Change that, via dongle, and a new image is loaded.
KISS - I2C is handled by the preboot software, not in Verilog itself. The serial boot ROM is in Verilog and I2C boot is super-simple code. I will post it if it helps. It doesn't have to do anything else, just bootstrap the "boot" ROM
KISS - I2C is handled by the preboot software, not in Verilog itself.
I'm not following - to read an external i2c device as a boot-replacement part, there is no software yet running - just the P2 HW loader, which is Verilog ?
The serial boot ROM is in Verilog and I2C boot is super-simple code. I will post it if it helps. It doesn't have to do anything else, just bootstrap the "boot" ROM
a) i2c needs to Start.AddressChipW then Write Address.Stop,. then Start.AddressChipR.RepeatedRead.ACK.
b) Auto-boot mode SPI parts just need a CLK to start, some few cycles skipped, then data clocks in, one bit per clock, until 16k.
c) Another solution could be a small MCU, that is configured as i2c slave only, Chip Address = 0xff, fixed read start address hardwired == ROM copy base.
Such a part can skip the Start.AddressChipW.WriteAddress.Stop, and can simply Start.AddressChipR.RepeatedRead.ACK, 0xff emits no address, just clocks.
Any of a), b) or c) can work - which choice is the simplest to 'get going' ? Verilog for a) seems the most complex, but it is only done once.
Maybe there is another choice
d) Emulate the ROM memory, in the P1 on the FPGA-123 board, I'm guessing there is 16k Bytes free on that ?
If not, P1 could hold P2 in reset, while it set the address and even read preamble on a standard i2c part, then release reset. P2 now takes over reading with just RepeatedRead.ACK, 8 of 9 clocks load valid data.
Yes, we need a way to load the ROM and then run it on reset.
I will make some mechanism to permit this. We will download, as usual, but run some code to stuff 16KB of the download into the ROM. On the next reset, the new ROM image loads and runs.
Yes, we need a way to load the ROM and then run it on reset.
I will make some mechanism to permit this. We will download, as usual, but run some code to stuff 16KB of the download into the ROM. On the next reset, the new ROM image loads and runs.
Thanks Chip, however you work it out as long as this mechanism doesn't interfere with the boot ROM under test. If this is in place I feel certain that working together we can get the boot ROM fully tested.
Could we get away with something as simple as loading 16KB to top of Hub from a 25C512 EEPROM on pins P0 & P1 and then run a clean boot from that???
If so, first 16KB or 3rd 16KB block of eeprom?
BTW Peter and I only need a BeMicro CV-A9 image.
I am working on adding my SD boot to the existing ROM boot. I should have that to you Tuesday sometime Chip.
The advantage of having the 16kB boot image in EEPROM is that we can test power-on reset. I would prefer this over the easier serial load method. There is no need for the prebooter to worry about serial or anything else, just load 16kB of EEPROM and run it.
If i2c is chosen, another option I see for simpler PC updates is UMFT201XE-01 - USB to i2c slave, up to 3.4MHz.
I've not used that specific FTDI part, but looks like you connect 3 wires : SCL, SDA, I2C_TXE#
Boot simply issues i2c READ (no need to write address first), checks I2C_TXE# before read of each byte, for handshake.
I guess you can prime the FT201, so it is ready with bytes when P2 wants them.
If i2c is chosen, another option I see for simpler PC updates is UMFT201XE-01 - USB to i2c slave, up to 3.4MHz.
I've not used that specific FTDI part, but looks like you connect 3 wires : SCL, SDA, I2C_TXE#
Boot simply issues i2c READ (no need to write address first), checks I2C_TXE# before read of each byte, for handshake.
I guess you can prime the FT201, so it is ready with bytes when P2 wants them.
We are only talking about a handful of these systems and this kind of thing is very easy to cobble together especially if we use a P1 so that it can even emulate the normal P2 loader, receive the file and program it directly into the EEPROM while holding reset then release. Once the boot ROM is confirmed there is never any need for this arrangement again.
We are only talking about a handful of these systems and this kind of thing is very easy to cobble together especially if we use a P1 so that it can even emulate the normal P2 loader, receive the file and program it directly into the EEPROM while holding reset then release. Once the boot ROM is confirmed there is never any need for this arrangement again.
Sure,anything that can work quickly and reliably....
Using the top half of a P1-eeprom would allow both to share the same memory.
We are only talking about a handful of these systems and this kind of thing is very easy to cobble together especially if we use a P1 so that it can even emulate the normal P2 loader, receive the file and program it directly into the EEPROM while holding reset then release. Once the boot ROM is confirmed there is never any need for this arrangement again.
Sure,anything that can work quickly and reliably....
Using the top half of a P1-eeprom would allow both to share the same memory.
Not a bad idea except maybe that the dongle needs to be left in for the P2 to boot though. I think it is simple enough to dedicate one for the job though and a 4-pin header for the dongle to plug into when needed. We want to be able to test everything as if it were the final device (almost).
Since the serial P2 boot allows to address multiple P2 chips on the same two wires, depending on a MASK of pins for identification, could you PLEASE, PLEASE, PLEASE integrate your multi-P1 communication protocol into the BOOT TAQOZ, using the same ID's as used in @CHIPS boot code?
That would give us a standard multi P2 communication protocol build into ROM.
I haven't really been able to spend any quality time on TAQOZ the last few weeks but despite the looming deadline I'm getting my poor head back into it. The hardest part is making it run from ROM and avoid other hub RAM as best as it can. That wasn't the original mission goal to keep it resident however that reminds me, I saw a truck the other day with a sign on it that said "we remove asbestos". Do you know how they remove asbestos? ...... as best as they can!
Ok, back onto the timeline, to make it fit I either have to whittle down the FAT32 virtual file system and compress the dictionary (that's ugly) or just not bother about FAT32 and rely on Cluso's routines for basic access. Maybe, that's an option to look at. Really need an instance of at least 20k of ROM though, it's a pity.
What I really wanted was a FPGA bootloader that didn't do any magic but just read an I2C EEPROM into ROM and ran it once only on power-up. But I have a question for Chip if he is not too busy (haha). COuld you explain what hubset $30000000 with a byte in byte 2 does in the ROM booter? I couldn't find it in the documentation. This is the code in question, and if it waits for a reset, does it only run at power-up and how?
' Load new ROM and wait for next reset
'
dat org
loc ptra,#$FC000 'ready to enter new data into rom
.lp rdbyte byte_data,ptra++ 'get new rom byte
setbyte rom_write,byte_data,#2 'install into command
hubset rom_write 'do rom write command
add rom_write,#1 'inc address in command
djnz byte_count,#.lp 'loop until 16KB loaded into rom
jmp #$ 'wait for reset
Comments
But none of that has to be relevant to today's implementation.
However, if we get into another debate as how to do it, it won't make the silicon for 22nd.
Adding a start address between the device-id and the data-part of the HEX or TXT loaders will not really need much code, neither on the P2 side nor for any external loader. just send 00000000 if you don't need multiple blocks or a different start address.
But this simple change would allow @peter and yourself to load code directly into the rom area at the end of the physical address-space without sending a HEX or BASE64 encoded text to send almost 4GB zeros and then your code.
Actual I got this idea while reading chips booter code. He just does it there. The first 4 lines just transfer a block into COG ram and a block into LUT ram.
It is somehow like ORGH in a SPIN2/PASM2 file, just for the serial loaders. Load this into the ROM area, load this at the end of ram and load this at the start of ram and run it.
The serial loader differs from flash, because flash just loads 2KB into COG 0 and runs it in COGexec, whereas the serial loader can load the complete HUB (except rom, arguable) and starts then in HUBexec.
So how is the SD connected in the current configuration and can we use one of those pins to check for pull up or not to distinguish between 'boot from sd, ignoring serial' and 'boot from sd, but give serial a chance'?
Is your sd boot code planned for loading into HUB like the serial loader or are you planning to just load a 2K chunk into the COG like the Flash one does?
And what pin would be available to signal that TAQOZ does not need to wait for serial boot loader to timeout before getting activated, reboot taking 60s is not so cool?
Mike
I tried to argue this a number of times but it fell on deaf ears.
would get together (at least virtually) to combine their efforts into one solution that will then be included.
You have to understand what is going on behind the scenes. Peter has needed to change direction with what I forsee as quite a major shift because his code is now needing to run from high hub instead of bottom hub.
My code is designed to be raw SD boot code whereas Peter's is based on full FAT32. It's a requirement that my SD boot code be able to cater for any future changes in SD card specifications, as much as humanly possible. So that is where I concentrated. Peter concentrated on Tachyon, using his existing FAT32 model.
I need to chat to Chip to implement my SD boot code, but he is still busy. I now also have work commitments.
Peter and I have both tried to get code changes in the existing ROM so we could test our changes easily, but due to Chip's time, that didn't happen.
We have a finite window that is closing fast. I am here just waiting.
Hey, license just occurred to me. You guys gonna knock out a quick license for Chip to keep everything nice and simple?
Probably should have a, "yeah, use it, no worries" exchange of intent here.
What exactly needs to change to speed testing ? - does that need a new thread ?
Hmm... I've seen that hinted at - is that because taqoz used word tokens as absolute address pointers for speed, and those work better on LSB=0 addresses ?
Is it smarter to map the ROM to low base, of 00H then ?
I guess Debug needs to be Hi and isolated, and not get in the way of compact/fast user code ? - and boot naturally goes into same area as debug
Maybe P2 needed something to better support memory relocation ( to late to add now..)
Ideally I would like to be able to load my code into the FPGA itself alongside Chip's code but I do know why we can't do that. If though Chip's FPGA boot code (or a version) simply read in the boot ROM from SPI Flash if present (better still, something completely independent like an I2C EEPROM on totally separate I/O and loaded via a P1 for testing) and loaded that into high mem then all of us could test the boot ROM. Now what Chip has now should allow that I guess but I would have to write a signed loader that fits into 1kB that then loads the "boot ROM" over the default boot ROM. To test it properly however it needs to go through Chip's final silicon boot process and since we have control of this image we would have hooks for simple SD user code and TAQOZ either interactively or with FAT32 user code.
The important thing is to have a final "boot ROM image" that works with the FPGA exactly as it would in silicon. The independent I2C EEPROM on say P56 & P57 would allow that and I am used to loading I2C EEPROM externally for production purpose and I have "dongles" that do that. So the idea would be I could take Chip's final boot code, integrate Cluso's and my code with it, load it into the EEPROM and then Chip's FPGA version preboot code could load 16k of that EEPROM unchecked and as-is into the boot ROM in upper memory and then we can let it run, just like it would in the silicon version. Maybe I can do that now with Chip's code but I like the independent memory idea because it's a bit like those expensive development versions of mask ROM or OTP micros we used to play with that had a socket on top of the chip that allowed you run the final code in an external memory chip, the same way it would run when it was locked into mask ROM.
I may have missed some important points but I needed to verbalize this so I could get a better picture of what I needed to do next. Now it's off to study Chip's boot code properly.
If Chip's loader read a Address,Size header, would that speed things enough ?
Ideally yes, but it will be hard to match that exactly as, the Verilog must differ somewhere to load the internal ROM, vs external pins.
That does mean that piece of code needs very careful visual checking and simulating
Interesting, not sure how much effort adding that is ? Certainly it's some verilog and testing time.
I did notice newer SPI parts have what is called fast-boot.
That allows a simple RST-CS-CLOCK sequence, which has to be getting very close to the ROM case ? (No address emitted, just a few dummy clocks)
Maybe Chip could map (RST).CS.SCK to 3 pins, for a part that is pre-configured to fast-boot ? You would need to externally load the SPI - can your "dongles" manage SPI ?
I'll check which Winbond parts support fast-boot...
Well the serial ROM in Verilog shouldn't be affecting any critical timing paths IMO. So the special FPGA dev version of a bootloader would not have to worry about anything else but loading an independent memory device on independent pins and I2C is just about as simple as it gets, we all know how they work and it only has to load the first 16kB of the EEPROM which sequentially at 1MHz (it doesn't matter if it assumes and uses the crystal) or so would take around 150ms although we are not that concerned about this boot time except of course in terms of Chip's serial boot but that can be handled a variety of ways. I use a small P1 board as a dongle, so I just send it a file, normally hex but other formats are easy to adapt, and then this loads it into the EEPROM directly while holding the P2 reset active. Once it releases it then the dev version preboot ROM in the FPGA simply loads in 16kB into $FC000 and runs it.
This way we can say with a high degree of confidence that the boot ROM will work as we expect it to since we have verified it to be so. I don't know if it is at all possible for that final 16kB boot image to be worked into the Verilog so that everybody could test it.
i2c is slow, and more complex to patch into Verilog, and is not quite the same as Serial ROM. Best to try and get as close to P2 as possible with external memory ?
A SPI-MCU in slave mode is another choice, but I think more work than a fast-boot mode SPI part.
Can your 'dongles' handle SPI parts ?
I find the MX25L12835FMI-10G as a stocked part, that has the fast-boot mode (just clock after reset), it can clock at 70~133MHz and takes a user choice of 7/9/11/13 clocks to issue data.
A header tag could easily auto-align, or an offset counter done.
That's a 16 pin part, so has the separate RST pin, and the same part allows QuadSPI testing - ie connect 2, one for user-code image, and one for the 'boot image in a corner'
Actually multiple boot images can be compared, via the Non Volatile FBR, 31 to 4 set the BOOT address. Change that, via dongle, and a new image is loaded.
The last 16KB end up in the ROM area.
Mike
a) i2c needs to Start.AddressChipW then Write Address.Stop,. then Start.AddressChipR.RepeatedRead.ACK.
b) Auto-boot mode SPI parts just need a CLK to start, some few cycles skipped, then data clocks in, one bit per clock, until 16k.
c) Another solution could be a small MCU, that is configured as i2c slave only, Chip Address = 0xff, fixed read start address hardwired == ROM copy base.
Such a part can skip the Start.AddressChipW.WriteAddress.Stop, and can simply Start.AddressChipR.RepeatedRead.ACK, 0xff emits no address, just clocks.
Any of a), b) or c) can work - which choice is the simplest to 'get going' ? Verilog for a) seems the most complex, but it is only done once.
Maybe there is another choice
d) Emulate the ROM memory, in the P1 on the FPGA-123 board, I'm guessing there is 16k Bytes free on that ?
If not, P1 could hold P2 in reset, while it set the address and even read preamble on a standard i2c part, then release reset. P2 now takes over reading with just RepeatedRead.ACK, 8 of 9 clocks load valid data.
I will make some mechanism to permit this. We will download, as usual, but run some code to stuff 16KB of the download into the ROM. On the next reset, the new ROM image loads and runs.
Thanks Chip, however you work it out as long as this mechanism doesn't interfere with the boot ROM under test. If this is in place I feel certain that working together we can get the boot ROM fully tested.
If so, first 16KB or 3rd 16KB block of eeprom?
BTW Peter and I only need a BeMicro CV-A9 image.
I am working on adding my SD boot to the existing ROM boot. I should have that to you Tuesday sometime Chip.
I've not used that specific FTDI part, but looks like you connect 3 wires : SCL, SDA, I2C_TXE#
Boot simply issues i2c READ (no need to write address first), checks I2C_TXE# before read of each byte, for handshake.
I guess you can prime the FT201, so it is ready with bytes when P2 wants them.
We are only talking about a handful of these systems and this kind of thing is very easy to cobble together especially if we use a P1 so that it can even emulate the normal P2 loader, receive the file and program it directly into the EEPROM while holding reset then release. Once the boot ROM is confirmed there is never any need for this arrangement again.
Using the top half of a P1-eeprom would allow both to share the same memory.
Not a bad idea except maybe that the dongle needs to be left in for the P2 to boot though. I think it is simple enough to dedicate one for the job though and a 4-pin header for the dongle to plug into when needed. We want to be able to test everything as if it were the final device (almost).
I have a question for you.
Since the serial P2 boot allows to address multiple P2 chips on the same two wires, depending on a MASK of pins for identification, could you PLEASE, PLEASE, PLEASE integrate your multi-P1 communication protocol into the BOOT TAQOZ, using the same ID's as used in @CHIPS boot code?
That would give us a standard multi P2 communication protocol build into ROM.
Enjoy!
Mike
https://bamil.pixnet.net/blog/post/47717082-[vivado]-how-to-change-firmware-rom-by-modifying-bitstream-(
Ok, back onto the timeline, to make it fit I either have to whittle down the FAT32 virtual file system and compress the dictionary (that's ugly) or just not bother about FAT32 and rely on Cluso's routines for basic access. Maybe, that's an option to look at. Really need an instance of at least 20k of ROM though, it's a pity.
What I really wanted was a FPGA bootloader that didn't do any magic but just read an I2C EEPROM into ROM and ran it once only on power-up. But I have a question for Chip if he is not too busy (haha). COuld you explain what hubset $30000000 with a byte in byte 2 does in the ROM booter? I couldn't find it in the documentation. This is the code in question, and if it waits for a reset, does it only run at power-up and how?