Loader to load any binary into Flash?
Peter Jakacki
Posts: 10,193
I see PNut lets me compile my kernel and load it into Flash ready to boot but is there anyway I can use my _BOOT_P2.BIX binary directly into Flash?
This would be make it easier for those who aren't using SD cards or who have problems with them to test out TAQOZ. Although they could load it into RAM, I just haven't yet added the extra Flash boot stage yet.
I have started writing a general-purpose booter called ReBooter to load SD much faster and also detect the latest binary images in Flash etc.
BTW - I modified my TAQOZ source so that PNut doesn't complain about certain symbols.
EDIT: I see flexprop will load Flash from a binary except it requires a checksum. The old Prop tool would do this for binary files too and it was so annoying because it didn't give you an option to override it.
I'm running on LM20.1.
Comments
Brian wrote the first code to do this, called P2ES_flashloader.spin2. There is a modified version of it included with loadp2. Flexprop uses it.
Chip's boot loader is much cleaner, partly because Chip's one doesn't support the revA chip.
P2ES_flashloader.spin2 is pure pasm and can be assembled with an attached pre-compiled binary. So you download to RAM the usual way and then it burns the attached binary to the EEPROM. Upon reset, the prop2 will then boot the EEPROM.
Chip's PNut will only compile then load that binary, whereas I just want it to load a binary. Flexprop wants a checksum.
So I might look at finishing off my ReBooter which will stay in Flash and let the ROM booter load this up so that it can load SD files fast and also arbitrary binary images in Flash.
I don't remember ever having to provide a checksum. I suspect it's automatic in loadp2. EDIT: It might be an optional thing that Eric has added.
EDIT2: Ah, I think the ROM code needs one embedded at end of first 1 KB of data in the EEPROM. This is automatically generated by P2ES_flashloader.spin2.
Here's Brian's original posting - https://forums.parallax.com/discussion/169608/prop2-flash-loader/p1
@"Peter Jakacki" : why do you say FlexProp requires a checksum for flash programming? I'm not aware of any such requirement... if something like that has crept in then I'd like to fix it!
I have to run this in Wine and it finds the serial port fine, but comes up with this error when I try to "Flash Binary File" and use _BOOT_P2.BIX renamed as taqoz.binary.
Seems if I specify the port it seems to Flash the binary but it doesn't boot. Ok, the booting part seems to be timing out trying to find some files on an SD card that isn't inserted. i can hit the escape four times and it prints out the "REBOOTING...." message which shows that TAQOZ must be working.
This sounds like the problem someone else had loading it into the Flash. That's the reason I was trying to load it into Flash in the first place. So now I will fix it up so it can work without an SD.
The "got incorrect initial checksum" error actually refers to an internal checksum calculated by the loader, not anything you have to supply. Basically it's saying that the download failed. Maybe the serial port doesn't work reliably under Wine? Have you tried running it natively? Even if the GUI doesn't work you could run the loadp2 command from the shell.
Yes, I got past that by specifying the port as I mentioned and now I can load it into Flash although I have to fix my autostart so it doesn't look for an SD card. I have loadp2 for Linux and it seems to work the same as the exe in your bin folder but I can't see where you can specify "Program Flash" with it.
I see what's happening. It thinks SD is present as it is reading a high on the SD CS but there's nothing there except a 1M pull-down on my P2D2. I will check it out a bit further.
By zeroing out the autostart vector in the binary before loading I can use TAQOZ in Flash. I've renamed this binary as taqoz-flash.binary.
EDIT: replaced the binary again with this one which still does the verbose reporting at boot but doesn't try to automatically run the media boot section.
I've had little trouble booting from flash, though I noticed early on the boot process does not complete without an SD card present. During the course of investigating problems with SD boot (specifically TAQOZ RELOADED v2.7), as a check I simply renamed _BOOT_P2. BIX to _BOOT_P2.bin and then using FlexProp programmed the binary in flash. Boots and runs as expected, again so long as an SD card is inserted.
loadp2 doesn't have a built in "Program Flash" option, but it does have the ability to load a program and data seperately. That's what flexprop uses to do the flash programming: it loads the P2ES_flashloader.bin program to 0 and the data for it (binary to flash) at 0x8000. The exact command line used may be discovered from the FlexProp Commands > Configure Commands menu option, but it's generally something like:
@ersmith Isn't there a fundamental problem/limitation with this approach in that you can only program P2 flash images that can fit within 480kB of flash instead of the full 512kB? Or am I missing something about how the 32kB offset works in loadp2?
This is where I get confused,
The largest program the P2 can load is 1020 bytes where the last 4 bytes are a checksum of Prop.
So that program then has to load the real program from flash and starts at address 0? If the first program is running from address 0 then it should overwrite itself and crash right?
Mike
Yes, there is a limitation that programs can be at most 480KB with this scheme. Most programs will have at least 32KB of RAM data, so this probably isn't a huge restriction.
The advantage of doing it this way is that the loader program is easily swappable, so the same method may be used to e.g. write _BOOT.PIX on an SD card (that's why the offset is at 32KB, too: the flash programmer is much smaller than that, but the FatFs based SD-card writer needs the room).
Typically the initlal bootstrap program (that fits in 1020 bytes) runs entirely from COG memory, so overwriting HUB memory with it is not a problem.
@ersmith ,
Wait a minute, addresses below $400 are cog ram so a program starting at address 0 is running from cog memory. So a boot program that starts at address 0 will over write itself.
Mike
Mike,
Real HubRAM exists between 0 and $400. And the typically RAM boot process loads the first program in that space. After the program is loaded in hubRAM, only then is it run with a COGINIT instruction. The COGINIT then copies the program from hubRAM into cogRAM before executing it. The hubRAM copy of the program can then be overwritten with anything else without interfering with the cogRAM execution.
EEPROM boot process just has an extra step infront of that.
PS: RDLONG/WRLONG only see hubRAM addresses. So addresses below $400 are not cogRAM to them. In fact only the pipeline code fetching sees the joint memory map. Everything else sees two distinct maps, with both maps starting at zero.
Ok. Maybe to solve this longer term I wonder if some amount of wait delay or a handshake was added between both downloaded stages/portions whether the initial flash loader in the first portion could somehow start up and also load itself fully into COG/LUT RAM and then continue with the serial download but again from address 0 to support the full 512kB HUB space again. Admittedly this requires some extensions to your "@8000+" syntax in loadp2 to indicate the two stage nature for checksumming but it might be useful for cases like this and avoids developing additional tools just for flashing that last 32kB.
Roger,
The $8000 address is only when burning the EEPROM, not booting from it. The boot process can load main code to hubRAM address zero.
Yeah, this is about flashing the entire 512kB of HUBRAM via loadp2 in case the image size exceeds 480kB. Booting up from flash still loads it into address 0.
I think the only way to get more when burning the EEPROM is to make it a multipart loading and burning process. Use the plan9 filesystem for grabbing pieces to be burnt ... or something. Then it can go far beyond 512 KB.
I noticed that the resident Flash loader expects a long at the start of the image at $10000 for the size. I had to store that value at $FFFFC in hub and copy from there to $10000 in Flash just so I could update the image from TAQOZ itself. Wouldn't it be better to store the size outside of the image? Even just before it at $FFFC?
Alternatively have the image address and size located in the loader's image, say at $3F0 (I placed the checksum immediately after the code to simplify loading the image).
For now I am using this loader and I can program an image of it into Flash if it is not already present.
Nonetheless, it is a much better scheme than Chip's Flash loader which expects the image to be immediately after the loader without even a 4K page break to allow the image to be erased independently of the loader.
Thanks for the loader and the help
So where does the actual flash image start for a P2 when booting up from SPI Flash? Is there a 64kB offset? I am wondering if something else can make use of the first 64kB of flash space (or other offset amount if it is non-zero)?
If the P2 boot code source is located somewhere I could dig around to look into it but I can't seem to find it ATM.
The code is there in the flexprop board source files so it is easy enough to "reclaim" that measly 64k, if you really wanted to. But considering that we are using 64MB devices, who cares?
I may use this source as the basis for my Rebooter that I will leave in the Flash as the main boot code so it will handle Flash images and SD boot files. The SD booter will fit into the cog along with the flashloader as I only need raw sector access and I will use the same MBR signature as Ray's SD boot code. Of course I could add the FAT32 stuff but it is also easy enough to find the boot file even in TAQOZ in ROM by doing a DIR which lists the start sector and write that sector number to the MBR.
I was wondering if another micro could boot from this SPI flash at address 0 while the P2 was in reset....and let the P2 boot from it later (at this 64k offset address if that is how it works)
The ROM booter loads the first 1 KB from the EEPROM. It's up to that small code to do the rest. Not unlike a boot block.
Yes, and I would have liked Chip to allow for both methods, his, and the general "boot anything from Flash" which means we could have loaded a larger loader, but now we have Chip's loader loading a 2nd stage loader which loads a 3rd stage loader for faster SD booting, which then loads the actual boot code. Unfortunately the ROM SD boot code wasn't made for speed and instead runs in hubexec loops which is dreadfully slow, hence the reason I would like to install my Rebooter code to Flash permanently.
Booter code is here. I don't think much if anything changed for the rev B respin (other than perhaps Cluso's SD fixes)
https://forums.parallax.com/discussion/168502/p2-rom-booter-serial-flash-sd-card-monitor-and-taqoz-features-and-operation/p1