So the the sd_cache_loader.binary file is the same thing as the image you write into the EEPROM when just specifying the -z flag, correct? The problem is that I don't want to specify the board's SD pins at the time the binary is written, but they are specified when the binary is run.
It seems like what is needed is a program that includes the cache driver DAT file, and knows where the SD pin descriptor needs to be patched into the DAT file. This should be a predicable location since I am only interested in the SD cache driver. After the program prompts the user for the SD pins, it then patches the DAT file, and then starts the SD cog. It then should be able to run the rest of the sd_cache_loader program at that point, correct?
The easiest way to do this would be to just link the sd_cache driver with your program rather than trying to patch it in. This can be done in a way similar to the way vm_start.S is linked into sd_cache_loader.elf. The problem is, I'd have to convert sd_cache.spin to sd_cache.S so that it could be assembled with gas. There is actually another way to handle this without having to make this conversion but it would be rather ugly since you'd end up with vm_start being handled differently than sd_cache even though both are COG drivers. I guess I should never have used any .spin files in the loader at all. Everything should have used gas.
However, this brings up the question of where these sources should live in your project. It's probably a bad idea for you to have your own copy of theses files because they could easily change between releases of PropGCC. I'm thinking that we should provide a generic way of doing this sort of thing so that we don't have internal code floating around in projects like the one you're planning. That is what will require a bit more thought.
Well I made some progress. The sdspi_config values are at longs 128 and 129 in the sd_cache.dat file, so that will be easy to patch. So I now get the following output from sd_cache_loader
propeller-load sd_cache_loader.elf -r -t
Propeller Version 1 on COM4
Loading sd_cache_loader.elf to hub memory
24320 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
sdspi_config1 = 090a0b13
sdspi_config2 = 19080005
Loading cache driver
Initializing SD card
Mounting SD filesystem
Opening AUTORUN.PEX
Loading kernel
Loading cluster map
Initializing cache
Well I made some progress. The sdspi_config values are at longs 128 and 129 in the sd_cache.dat file, so that will be easy to patch. So I now get the following output from sd_cache_loader
propeller-load sd_cache_loader.elf -r -t
Propeller Version 1 on COM4
Loading sd_cache_loader.elf to hub memory
24320 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
sdspi_config1 = 090a0b13
sdspi_config2 = 19080005
Loading cache driver
Initializing SD card
Mounting SD filesystem
Opening AUTORUN.PEX
Loading kernel
Loading cluster map
Initializing cache
So it seems to be stuck initializing the cache.
How did you get the sd cache driver linked in?
Also, I think it's a bad idea to assume that the SD parameters will always be at those offsets. This is all done with symbols in propeller-load to protect against things changing between versions of PropGCC.
I used bin2c to generate an sd_cache.c file, and added that to the the makefile. I think for now I can use the hard-coded addresses. BTW, I got the XMMC program to run! I had to copy the address of xmm_mbox to location $6. I am getting stdout output, but it's not responding to the input. I do get characters echoed back when I type. I'll have to add some debug prints to my XMMC program to see why it isn't getting the input.
I used bin2c to generate an sd_cache.c file, and added that to the the makefile. I think for now I can use the hard-coded addresses. BTW, I got the XMMC program to run! I had to copy the address of xmm_mbox to location $6. I am getting stdout output, but it's not responding to the input. I do get characters echoed back when I type. I'll have to add some debug prints to my XMMC program to see why it isn't getting the input.
I'm glad to hear you're making progress but if this sort of thing is going to be common we need a more future-proof way of handling it.
You may have seen the pfth ANS Forth interpreter that I posted in another thread. It's an XMMC program that loads and executes Forth files from an SD card. Since it requires an SD card I know that I will always be able to run it from the SD card. For my purposes I have been using SimpleIDE to compile and run the program. BTW, I really like the file transfer feature in SIDE. It makes it easy to write Forth code on the PC, transfer it to the Prop's SD card, and then run the Forth interpreter -- all from SIDE.
Most Forth developers don't use PropGCC, so I need a way to provide the cache loader and XMMC binaries, which can then be configured for their particular SD pin connections. My plan was to adapt David's SD cache loader to do this, but I can't quite figure out how to do this. I'm sure I can figure it out eventially, but I was hoping to save some time.
At some point I want to run XMMC programs under spinix also. In that case the cache loader program would be a file on the SD card. This could be more flexible and use .cfg files to allow execution from other types of memory, such as flash or RAM. However, the EEPROM boot program is my more immediate need, and the OS version of the loader could be done later.
I got lost in the details of your original question and forgot to respond to the original motivation behind it. Why can't you distribute your code as a .elf file with a few .cfg files for the boards you intend to support. There is no need to install all of PropGCC just to use the loader to write your forth interpreter to the SD card and the sd_cache_loader to eeprom. That can be done with just propeller-load itself. Are you not using propeller-load because it isn't a GUI program? I've been thinking about making a GUI version of it just for this sort of thing. Would that solve your problem?
Using propeller-load would be a good way to go, but it means that I would need to provide the linux, Windows and Mac versions of the program plus all the .cfg files. I would also need to provide instructions for making a custom .cfg file for non-standard boards. By providing an sd_cache_loader program I only need to provide two files. Actually, I may need a few other versions for boards that don't use a 5 MHz crystal.
Using propeller-load would be a good way to go, but it means that I would need to provide the linux, Windows and Mac versions of the program plus all the .cfg files. I would also need to provide instructions for making a custom .cfg file for non-standard boards. By providing an sd_cache_loader program I only need to provide two files. Actually, I may need a few other versions for boards that don't use a 5 MHz crystal.
Yes but the people who use those two files still need to have the Propeller Tool or BST installed. If there was a standalone install of propeller-load available on the Parallax web site for Windows, Linux, and Macintosh you could just point them to that. You wouldn't really need any .cfg files if you're willing to use propeller-load command line arguments to set the various settings. Again, all of this stuff would be easier with a propeller-load GUI I suppose. I'll have to work on that.
Anybody who uses the Prop should already have the Prop Tool or BST installed. There's a much smaller set of Prop developers that use the SimpleIDE, and an even smaller group that uses PropGCC from the command line.
A propeller-load GUI might be useful. I suppose it could be implemented as a subset of the SimpleIDE. It might be viewed as a Prop installer program, where it would write a boot program to the EEPROM and data files to the SD card. Now that would be nice to have. This way a developer could distribute binaries and data files that need to go on an SD card, and the end user could configure the installation for his particular environment.
BTW, I found the real problem with my modified version of sd_cache_loader -- it was too big! The cache is hard-coded at $6000 and the mailboxes are just before that. My program was slightly larger than 24K, so the mailboxes were sitting in the BSS. I removed some code and got it down to less than 24K, and it works fine. Now I need to figure out how to prompt the user for the SD pins, and maybe also the clock configuration, store that to EEPROM and keep the program under 24K in size. I tried CMM mode, but that didn't work for some reason. I'll work with CMM a bit more to see if I can get that to work, or maybe I can declare a small dummy array that straddles the 24K boundary so I don't clobber the mailboxes. It's a kludge, but it should work.
Or I could use propeller-load and provide instructions on where to get it and how to make a customized .cfg file for their hardware platform. That may be the best approach. I'll probably need to gather the various flavors of the propeller-load executable from the different installation builds. Or I could wait for the Prop installer GUI program.
Anybody who uses the Prop should already have the Prop Tool or BST installed. There's a much smaller set of Prop developers that use the SimpleIDE, and an even smaller group that uses PropGCC from the command line.
A propeller-load GUI might be useful. I suppose it could be implemented as a subset of the SimpleIDE. It might be viewed as a Prop installer program, where it would write a boot program to the EEPROM and data files to the SD card. Now that would be nice to have. This way a developer could distribute binaries and data files that need to go on an SD card, and the end user could configure the installation for his particular environment.
BTW, I found the real problem with my modified version of sd_cache_loader -- it was too big! The cache is hard-coded at $6000 and the mailboxes are just before that. My program was slightly larger than 24K, so the mailboxes were sitting in the BSS. I removed some code and got it down to less than 24K, and it works fine. Now I need to figure out how to prompt the user for the SD pins, and maybe also the clock configuration, store that to EEPROM and keep the program under 24K in size. I tried CMM mode, but that didn't work for some reason. I'll work with CMM a bit more to see if I can get that to work, or maybe I can declare a small dummy array that straddles the 24K boundary so I don't clobber the mailboxes. It's a kludge, but it should work.
Or I could use propeller-load and provide instructions on where to get it and how to make a customized .cfg file for their hardware platform. That may be the best approach. I'll probably need to gather the various flavors of the propeller-load executable from the different installation builds. Or I could wait for the Prop installer GUI program.
I still think that it would be better to have a PC-based program to allow the user to configure your program for a particular board. It shouldn't be too hard to make a simple GUI that sits on top of propeller-load and lets you set the parameters that are normally read from a .cfg file. The advantage of this approach is that you don't have to worry about complex code running on the Propeller that might not fit in hub memory.
Also, how are you going to prompt for clock parameters? Isn't that a chicken-and-egg problem? Your program that prompts for settings wouldn't even be running unless the clock settings were correct would it?
There is a faster micro-SD plug-in alternative coming of course
Could you give the hardware requirements for this? I'm designing a board with micro-SD, and it would be nice to keep this as an option. I'll be switching over to PropGCC sometime in the next few weeks, if all goes well.
I think I can run the serial port when using the fast internal RC clock. That's how the normal download process works, right? The baud-rate may be limited however.
I'll probably just use the current propeller-load, and provide instructions on how to use it. Thanks for your help.
I think I can run the serial port when using the fast internal RC clock. That's how the normal download process works, right? The baud-rate may be limited however.
I'll probably just use the current propeller-load, and provide instructions on how to use it. Thanks for your help.
Yes, the first load uses the internal RCFAST, but other pasts of the load sequence use the .cfg parameters to get best download performance.
It should be very easy for some who has time and the Qt development environment to make a propeller-load QtGUI. Sadly, the shared libraries are huge, so the benefit might not be very clear. Try using Geany. It is relatively small and has some tool definition ability. Propeller loaders are painful especially on the MAC.
Could you give the hardware requirements for this? I'm designing a board with micro-SD, and it would be nice to keep this as an option. I'll be switching over to PropGCC sometime in the next few weeks, if all goes well.
So just to close the loop on how I solved my problem I've attached the zip file below that I posted in the pfth thread. Basically, I included a copy of propeller-load.exe and all the .dat and .cfg files in a config subdirectory. The readme.txt file tells the user how to install the files using the install.bat file. I think this is the best approach for what I wanted to do. The only limitation is that it doesn't support MACs or Linux. I would have to include every flavor of propeller-load to do that.
Something that might be nice is to make the various versions of propeller-load available in the PropGCC download section in a single file. This way we could direct a user to the site to download the version he needs.
Comments
However, this brings up the question of where these sources should live in your project. It's probably a bad idea for you to have your own copy of theses files because they could easily change between releases of PropGCC. I'm thinking that we should provide a generic way of doing this sort of thing so that we don't have internal code floating around in projects like the one you're planning. That is what will require a bit more thought.
propeller-load sd_cache_loader.elf -r -t
Propeller Version 1 on COM4
Loading sd_cache_loader.elf to hub memory
24320 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
sdspi_config1 = 090a0b13
sdspi_config2 = 19080005
Loading cache driver
Initializing SD card
Mounting SD filesystem
Opening AUTORUN.PEX
Loading kernel
Loading cluster map
Initializing cache
So it seems to be stuck initializing the cache.
Also, I think it's a bad idea to assume that the SD parameters will always be at those offsets. This is all done with symbols in propeller-load to protect against things changing between versions of PropGCC.
A propeller-load GUI might be useful. I suppose it could be implemented as a subset of the SimpleIDE. It might be viewed as a Prop installer program, where it would write a boot program to the EEPROM and data files to the SD card. Now that would be nice to have. This way a developer could distribute binaries and data files that need to go on an SD card, and the end user could configure the installation for his particular environment.
BTW, I found the real problem with my modified version of sd_cache_loader -- it was too big! The cache is hard-coded at $6000 and the mailboxes are just before that. My program was slightly larger than 24K, so the mailboxes were sitting in the BSS. I removed some code and got it down to less than 24K, and it works fine. Now I need to figure out how to prompt the user for the SD pins, and maybe also the clock configuration, store that to EEPROM and keep the program under 24K in size. I tried CMM mode, but that didn't work for some reason. I'll work with CMM a bit more to see if I can get that to work, or maybe I can declare a small dummy array that straddles the 24K boundary so I don't clobber the mailboxes. It's a kludge, but it should work.
Or I could use propeller-load and provide instructions on where to get it and how to make a customized .cfg file for their hardware platform. That may be the best approach. I'll probably need to gather the various flavors of the propeller-load executable from the different installation builds. Or I could wait for the Prop installer GUI program.
Also, how are you going to prompt for clock parameters? Isn't that a chicken-and-egg problem? Your program that prompts for settings wouldn't even be running unless the clock settings were correct would it?
Could you give the hardware requirements for this? I'm designing a board with micro-SD, and it would be nice to keep this as an option. I'll be switching over to PropGCC sometime in the next few weeks, if all goes well.
I'll probably just use the current propeller-load, and provide instructions on how to use it. Thanks for your help.
Yes, the first load uses the internal RCFAST, but other pasts of the load sequence use the .cfg parameters to get best download performance.
It should be very easy for some who has time and the Qt development environment to make a propeller-load QtGUI. Sadly, the shared libraries are huge, so the benefit might not be very clear. Try using Geany. It is relatively small and has some tool definition ability. Propeller loaders are painful especially on the MAC.
I'll send you a PM. Done.
Something that might be nice is to make the various versions of propeller-load available in the PropGCC download section in a single file. This way we could direct a user to the site to download the version he needs.