XMM load without propeller-load

steddyman

Is there any way to get PropGCC to output a BIN file for the code that runs in hub/cog ram along with an SD loader to load the rest of the code into either Flash or SRAM?

The reason I ask is I have a Micromite Companion (MMC) which can load BIN files, and I would like to get it to then load the XMM portion from the SD. I can created a Config file for my board type but I can't get the GCC Compiler to output a BIN and a PEX file I can put on the SD. The example I am using is generating a .COG, a .ELF and a .PEX.

If I instead compile to LMM then I get a straight BIN that the MMC will load just fine.

David Betz

steddyman wrote: »

Is there any way to get PropGCC to output a BIN file for the code that runs in hub/cog ram along with an SD loader to load the rest of the code into either Flash or SRAM?

The reason I ask is I have a Micromite Companion (MMC) which can load BIN files, and I would like to get it to then load the XMM portion from the SD. I can created a Config file for my board type but I can't get the GCC Compiler to output a BIN and a PEX file I can put on the SD. The example I am using is generating a .COG, a .ELF and a .PEX.

If I instead compile to LMM then I get a straight BIN that the MMC will load just fine.

The sources for the SD loader are in the propgcc repository. You should be able to use those as a basis for an XMM loader that you can use on your MMC. I guess the idea would be to download the XMM loader and then have it load the .PEX file from the SD card. What external memory are you planning to use for XMM?

Yes, you can generate a .binary for LMM or CMM programs. There is no way, of course, to do that for XMM programs since the .binary loader in the Propeller chip knows nothing about external memory.

Dave Hein

It should be possible, but it hasn't been done yet. You should be able to create an XMMC executable that will run from an SD file. The loader will put the PEX file on the SD card with a default name that I can't recall right now. It will also burn the loader program into EEPROM. The loader program will run on bootup, and setup the prop to run the XMMC program stored in the default PEX file.

I believe the XMMC boot program is written in Spin, so it should be possible to build an version of the boot program that can be loaded from SD and executed. It should also be possible to modify the XMMC boot program to run any arbitrary PEX file on the SD card.

Now if that can be done, then it should be possible to further modify the XMMC boot program to copy the PEX file to Flash or SRAM, and execute it from there. It's just a simple matter of programming.

EDIT: It looks like David Betz responded at the same time that I was composing my message.

steddyman

Thanks, I will take a look at the sources.

I have a simple SPI SRAM hooked up to the breadboard of th MMC and tested to be working using SPIN code.

Dave Hein

So in the propgcc/loader/sdloader source directory there are 2 LMM C programs call sd_loader and sd_cache_loader. The first one is used with external memory and the second one is used to execute directly out of the SD card. They load the file autorun.pex and run it.

David Betz

Dave Hein wrote: »

So in the propgcc/loader/sdloader source directory there are 2 LMM C programs call sd_loader and sd_cache_loader. The first one is used with external memory and the second one is used to execute directly out of the SD card. They load the file autorun.pex and run it.

I don't recommend running code directly off of the SD card as the cache driver for that mode must use 512 byte cache lines because that is the smallest amount you can read from the SD card. Cache lines of that size don't perform very well. You're much better off using a SPI flash or SRAM. Sounds like steddyman has a SPI SRAM available so that is probably the best approach.

Dave Hein

So steddyman should use sd_loader to copy the PEX file to SRAM, correct?

I agree that the 512-byte cache line size is a problem with running from SD directly. I think the problem is actually due to there only being 16 cache lines when the cache is 8K in size, and the cache lines are 512 bytes. I think direct SD execution could be improved if the 512-byte block size where broken up into 4 128-byte cache lines. A 512-byte buffer could be used to hold the SD sector, but only 128 bytes would be used at a time. However, we didn't pursue this idea at the time when the cache driver work was being done.

I think executing from SD is still a useful thing for systems that have no other external memory, but do have an SD card.

David Betz

Dave Hein wrote: »

So steddyman should use sd_loader to copy the PEX file to SRAM, correct?

I agree that the 512-byte cache line size is a problem with running from SD directly. I think the problem is actually due to there only being 16 cache lines when the cache is 8K in size, and the cache lines are 512 bytes. I think direct SD execution could be improved if the 512-byte block size where broken up into 4 128-byte cache lines. A 512-byte buffer could be used to hold the SD sector, but only 128 bytes would be used at a time. However, we didn't pursue this idea at the time when the cache driver work was being done.

I think executing from SD is still a useful thing for systems that have no other external memory, but do have an SD card.

We could do that and I thought about it myself but we end up having to read 512 bytes each time even though we only store 128 bytes. I guess we'd have to try it to find out if it helps. Actually, if we had a separate sector buffer we could treat that as a second level one line cache and check for a hit there before reading a new sector. That way we would get faster execution of straight line code that spans 128 byte (or whatever) cache lines but is in the same SD sector.

Dave Hein

Yes, I was suggesting having a separate sector buffer, and only copy 128 bytes at a time from it. So with 128-byte cache lines the cache driver would first check to see if the 128-byte chunk is already sitting in the sector buffer before it would read a new sector.

I tried compiling sd_cache_loader and putting it on an SD card along with a test PEX file. However, the loader never got past the call to the mount routine. Even if it was able to access the SD card I don't think it would work because the caching interface has changed, and I suspect the SD driver was never updated to the new method.

David Betz

Dave Hein wrote: »

Yes, I was suggesting having a separate sector buffer, and only copy 128 bytes at a time from it. So with 128-byte cache lines the cache driver would first check to see if the 128-byte chunk is already sitting in the sector buffer before it would read a new sector.

I tried compiling sd_cache_loader and putting it on an SD card along with a test PEX file. However, the loader never got past the call to the mount routine. Even if it was able to access the SD card I don't think it would work because the caching interface has changed, and I suspect the SD driver was never updated to the new method.

You're right that I never updated the SD cache driver for the new cache interface. I wasn't sure we really wanted to retain the SD cache driver because of its bad performance. You could try this experiment in the release_1_0 branch instead just to see if it improves performance well enough to bother moving it to the default branch.