propgcc installs x86 binary of openspin on ARM machines.
Heater.
Posts: 21,230
propgcc installs an x86 binary of openspin on non-x86 architectures when building for linux. In my case the Raspberry Pi.
This in turn causes the build of propeller-load to fail.
Which poses a question in my mind.
Why does propgcc include propeller-load? Perhaps that should be broken out as a separate project and repo as it is not really part of the compiler.
propeller-load requires openspin (or previously BSTC) to be installed but it should not really be carrying around binaries of openspin.
openspin sources in turn should not be included in propgcc as it is a separate thing altogether.
The good news is that propeller-load does indeed build on the Pi now with openspin.
This in turn causes the build of propeller-load to fail.
Which poses a question in my mind.
Why does propgcc include propeller-load? Perhaps that should be broken out as a separate project and repo as it is not really part of the compiler.
propeller-load requires openspin (or previously BSTC) to be installed but it should not really be carrying around binaries of openspin.
openspin sources in turn should not be included in propgcc as it is a separate thing altogether.
The good news is that propeller-load does indeed build on the Pi now with openspin.
Comments
Look at the propgcc/jbuild.sh, propgcc/loader/build.sh, and propgcc/loader/Makefile. Then imagine a solution.
Script propgcc/loader/build.sh can be used to build propeller-load without building the whole thing.
It would be easy enough to make a new propeller-load repository, but maintenance is harder with N copies.
The solution I imagine is that propeller-load is not included in propgcc at all. I get the impression that most targets of GCC don't carry device loaders around with them.
The compiler is the compiler and the loader is the loader, they could be totally separate projects and repositories.
I can build the loader just fine.
My issue is with propgcc carrying binaries around in the source repo.
It's not a big deal for me, it's just odd.
The build scripts / make select openspin by OS at the moment. There needs to be some decision on what to do based on the architecture.
Moving propeller-load to its own repository is a non-starter at the moment because it is still being "maintained" in various branches of the propeller-gcc repository.
The loader depends on the "virtual machine" defined by propgcc, so it needs to track changes in that and so it needs to be part of propgcc. That's kind of ikky but I don't see any way around it.
The loader requires openspin (or BSTC) to build. It does not follow that openspin binaries should be included in the propgcc source code repo. There should never be such binaries in a source code repo.
On the other hand openspin is it's own separate project so we should not include openspin sources in propgcc and build it as part of building propgcc.
Which leads to the simple conclusion that it is just a requirement that openspin is installed on your system before attempting to build propgcc.
This is normal. After all there are a ton of other dependencies you need on your system in order to build GCC.
Also, the loader doesn't really know much about the XMM kernel. All it really knows is the interface to the external memory driver and how to adjust the cache parameters based on what is in the board configuration file.
One might ask why the loader needs openspin to compile those .dat files as propgcc has gas? Is it just that the PASM syntax is preferable ?
I agree that it would be nice to split things up into smaller projects. I'd also like to have a Makefile to replace jbuild.sh so that a failure near the end of the build process doesn't require starting over from the beginning. No one has had time to write that Makefile though so we continue to use jbuild.sh which does the job nicely if not quite as efficiently as we might like.
This isn't very clear
We do have C code that can write data to an SD card.
Is that because we need to waste about 2KB on a CMM/LMM kernel ?
#include <stdio.h> extern _Driver _SimpleSerialDriver; extern _Driver _FileDriver; _Driver *_driverlist[] = { &_SimpleSerialDriver, &_FileDriver, NULL }; int main(void) { int i; FILE *infile = fopen("dummy", "r"); FILE *outfile = fopen("dummy", "w"); fread(&i, 1, 1, infile); fwrite(&i, 1, 1, outfile); return 0; }Commenting out the fopen and fwrite for the output file save 628 bytes for LMM and 316 bytes for CMM. The extra bytes are for the generic fwrite function, but the file system code always pulls in all the read, write and directory support. The functions chdir, mkdir and rmdir would bring in extra code, but you don't need them if you are just working with the root directory.
EDIT: If we need a smaller file system that only supports the root directory we could port the FSRW code. We could probably get a minimal program down below 8K with FSRW in CMM.
Thanks!
David