But we are going to need to test the booting of both FLASH and SD before you put it out in files.
I'm not quite following this comment ?
Chip is not working on SD, so he needs to first release files, so that others can test that.
Chip does have working Serial Boot (I think with 1 pin too?) and working SPI boot, but the preamble, pin-mapping and decision tree are tbf.
I'd suggest Chip adds a Quad-Exit preamble (from other thread) and release files with any SPI pin out that can easily test boot.
A single pinout will do, for now, one that readily allows Quad-Exit tests makes the most sense.
Then field tests can be done, (including SD), and final pin-map candidates decided on.
Another future ROM pass then merges any fixes, new Pin-maps, and SD code, for testing.
But we are going to need to test the booting of both FLASH and SD before you put it out in files.
I'm not quite following this comment ?
Chip is not working on SD, so he needs to first release files, so that others can test that.
Chip does have working Serial Boot (I think with 1 pin too?) and working SPI boot, but the preamble, pin-mapping and decision tree are tbf.
I'd suggest Chip adds a Quad-Exit preamble (from other thread) and release files with any SPI pin out that can easily test boot.
A single pinout will do, for now, one that readily allows Quad-Exit tests makes the most sense.
Then field tests can be done, (including SD), and final pin-map candidates decided on.
Another future ROM pass then merges any fixes, new Pin-maps, and SD code, for testing.
Yes, I am working on the SD boot code. Peter will assist once I get a bit further along.
Currently I am using P1 for testing as its simpler than using the FPGA.
I am not up-to-date with the latest P2 FPGA boot code. (I used the latest v10x code last time I ran P2 FPGA).
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. I'm sorry I've been around and around with this, but I don't think we have the right solution, yet.
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. .
That sequence makes sense.
If someone does want to pin-overlap & use both in a design, they have Flash, so can map their own SD overlay.
+1
But we are going to need to test the booting of both FLASH and SD before you put it out in files.
Chip,
What is the current state of the Boot ROM in release 11b ?
ie What does it do? Do we require a FLASH device present?
I want to be able to load P2 code (without reloading/repowering the FPGA board) to test the SD Card (on other pins initially) to confirm everything works fine at least for me before I release it into the wild for testing.
I would presume the same will be required for FLASH testing. I have S25FL116X here to test when Boot FLASH code is ready for download & test.
Maybe we don't need something external to boot from (which is why I suggested EEPROM on the other thread even if it does not make it into the final Boot ROM, even tho' I think it would make a great reliable option)
Version 11b boots from flash, if present, but due to a bug, you need pull-up resistors on both CSn and CLK. I've got that fixed, but not released yet. If you look at the latest Google doc, there is a section on booting that explains what happens, in detail.
I wrote a small program that programs a program into the SPI flash device so that it can run on boot-up. I'll be adding that into the next release. Ultimately, we'll need that integrated into the tools, so that you can automatically program a bootable SPI flash image.
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. I'm sorry I've been around and around with this, but I don't think we have the right solution, yet.
As booting from a memory device goes, I think exclusively SPI flash or SD card would be good. I don't know if there's really much reason to make the two things coexist simultaneously on the same pin map, if it causes any conflicts. One or the other would be fine. The boot ROM could try SPI flash first, since it's simpler and faster, and then check for an SD card. .
That sequence makes sense.
If someone does want to pin-overlap & use both in a design, they have Flash, so can map their own SD overlay.
+1
But we are going to need to test the booting of both FLASH and SD before you put it out in files.
Chip,
What is the current state of the Boot ROM in release 11b ?
ie What does it do? Do we require a FLASH device present?
I want to be able to load P2 code (without reloading/repowering the FPGA board) to test the SD Card (on other pins initially) to confirm everything works fine at least for me before I release it into the wild for testing.
I would presume the same will be required for FLASH testing. I have S25FL116X here to test when Boot FLASH code is ready for download & test.
Maybe we don't need something external to boot from (which is why I suggested EEPROM on the other thread even if it does not make it into the final Boot ROM, even tho' I think it would make a great reliable option)
Version 11b boots from flash, if present, but due to a bug, you need pull-up resistors on both CSn and CLK. I've got that fixed, but not released yet. If you look at the latest Google doc, there is a section on booting that explains what happens, in detail.
I wrote a small program that programs a program into the SPI flash device so that it can run on boot-up. I'll be adding that into the next release. Ultimately, we'll need that integrated into the tools, so that you can automatically program a bootable SPI flash image.
Comments
I'm not quite following this comment ?
Chip is not working on SD, so he needs to first release files, so that others can test that.
Chip does have working Serial Boot (I think with 1 pin too?) and working SPI boot, but the preamble, pin-mapping and decision tree are tbf.
I'd suggest Chip adds a Quad-Exit preamble (from other thread) and release files with any SPI pin out that can easily test boot.
A single pinout will do, for now, one that readily allows Quad-Exit tests makes the most sense.
Then field tests can be done, (including SD), and final pin-map candidates decided on.
Another future ROM pass then merges any fixes, new Pin-maps, and SD code, for testing.
Yes, I am working on the SD boot code. Peter will assist once I get a bit further along.
Currently I am using P1 for testing as its simpler than using the FPGA.
I am not up-to-date with the latest P2 FPGA boot code. (I used the latest v10x code last time I ran P2 FPGA).
Version 11b boots from flash, if present, but due to a bug, you need pull-up resistors on both CSn and CLK. I've got that fixed, but not released yet. If you look at the latest Google doc, there is a section on booting that explains what happens, in detail.
I wrote a small program that programs a program into the SPI flash device so that it can run on boot-up. I'll be adding that into the next release. Ultimately, we'll need that integrated into the tools, so that you can automatically program a bootable SPI flash image.