Proposed loadp2 changes
ersmith
Posts: 5,910
in Propeller 2
I'm working on some changes to loadp2 and would like some feedback from interested parties before I release an "official" version. The changes affect only the fast loader (-CHIP) and add the following features:
(1) Autobaud detection: the fast loader no longer relies on the frequency and clock settings sent by the host to be accurate. It does apply the clock mode setting (so it will be running faster than RCFAST) but it doesn't use the frequency; instead the host sends some space characters and the fast loader detects those and sets the baud accordingly. This should allow downloads to work on boards other than the P2ES without needing an accurate -f option, so the defaults for FlexGUI will (I hope) work for all boards.
(2) Multiple file support: loadp2 can load multiple files into memory at the same time. For example you can do something like:
The changes are in github now, so if you're able to build and test them I'd like to hear your results. Suggestions for improvements to these features are also welcome.
Eric
(1) Autobaud detection: the fast loader no longer relies on the frequency and clock settings sent by the host to be accurate. It does apply the clock mode setting (so it will be running faster than RCFAST) but it doesn't use the frequency; instead the host sends some space characters and the fast loader detects those and sets the baud accordingly. This should allow downloads to work on boards other than the P2ES without needing an accurate -f option, so the defaults for FlexGUI will (I hope) work for all boards.
(2) Multiple file support: loadp2 can load multiple files into memory at the same time. For example you can do something like:
loadp2 -b230400 @0=vgaprog.bin,@1000=picture.bmpto load vgaprog.bin at 0 and picture.bmp at $1000, and then execute vgaprog.bin. The loaded data may optionally be preceded by its size by usiing "@ADDR+" instead of "@ADDR=". For example:
loadp2 -b230400 @0=flashloader.bin,@1000+myprog.binwill put the size of "myprog.bin" at $1000 and the actual contents of myprog.bin at $1004.
The changes are in github now, so if you're able to build and test them I'd like to hear your results. Suggestions for improvements to these features are also welcome.
Eric
Comments
Maybe loadp2 can take a Xtal spec (default 20MHz) and a SysCLK desired, and create a clock setting itself (which it reports).
The placement only works in HUB memory; loadp2 still doesn't understand how to program boot EEPROM. Indeed, the multi-file support is how I plan to implement programming EEPROM, since it allows us to download a flash programmer (like yours) and a file to program, without having to re-compile the flash programmer.
Unfortunately I'm having trouble with flash programming this way. Really simple LED blink type programs work with this scheme, but longer programs do not. I don't think it's a problem with the loader itself (the loadp2 fastload code has a checksum and seems to be working). More likely it's some bad interaction between the loader and flash programmer, or a misunderstanding I have about how the flash programmer works, or (probably less likely) a bug in the flash loader... it almost acts as though it's only programming the first part of the downloaded code.
First part is is a fixed 1 kByte in length and is what the ROM will initially load from the SPI chip. It has a checksum in the last longword. Brian has this padded, with an ORGF $100, so that the adjoining main code is not overlapping the runtime placed checksum.
Second part has a "size" value to also be filled at programming runtime. This tells the second stage booter how many bytes to read to load the main program. If left at a value of zero then it won't complete the boot.
If you leave off the "@1000+whatever.bin" then the flash loader just programs a blinking LED, as it did before. But if you add it, then the code in the flash loader (including the code size, in the first long) gets overwritten by the 4 byte size of whatever.bin followed by the file data.
Thanks for your help!