I changed them on purpose--the locations loadp2 uses will intersect with the entry routine. So if you use the patching in loadp2 it will not function properly. So to use the locations from loadp2, we'd need to change how startup works to add a function to jump over those locations. In fact, looking at it now, even my locations intersect if you patch it in... so maybe the best course of action is to move the entry function, and make the instruction at 0x00 just jump to that function
As an aside, where do those addresses come from? Convention from P1? Is there a specific reason we need to keep those values at those addresses, or can we leave it up to compiler implementation to define? It would make patching when loading a bit more difficult, because you'd need to specify where to patch the values, but adds flexibility.
Dave Hein came up with those numbers who wrote the loadp2 code. Chip had some numbers as well but I don't think they match. And yes, the P1 had similar items.
Dave Hein came up with those numbers who wrote the loadp2 code. Chip had some numbers as well but I don't think they match. And yes, the P1 had similar items.
@iseries said:
Where does Chip put his debug code? He uses similar addresses.
Mike
Not sure, but hubset to enable cog 0 debugging needs to be called before coginit for cog 0, so it needs to happen in __entry. Actual debugger code lives in debug space at the end of RAM
That's a good one. My Cmake does not work for that so I used make instead. There are some leftover make files in each folder that when you run make it will create a build folder and put the two archives in it. Those need to be copied out to the p2llvm folder.
Don't know if you can get cmake to work for you but you can also try that. cd to libp2 and run cmake I think.
I could also give you a copy of libc.a and libp2.a but these would be custom build and not the official versions, but I know they work.
Please note that programs that are compiled with libp2.a have debug code in them and will generate bloated programs (512k) in size. This does not represent the program size just that in order to load them as one file they need to load the dead space as well.
I disabled the debug code and my compiles are around 25k for a simple program.
If you use the downloaded build, libp2.a no longer contains debug code--that now lives in libp2db.a, so if you don't link p2db, no debugging code should be included.
Only thing is that I think it will still try to load 0's for that section of code, which is at the end of ram, so if you first use objcopy to convert the elf to load a bin, it will load significantly faster cause it will ignore all of that.
@n_ermosh I downloaded libp2.a from Zemon's CI server using your link and it compiled.
But, my nearly empty program produced a 521 kB elf file.
So, maybe it's still in that one?
Also, it seems I need to compile loadp2.exe as well.
Is this the same loadp2 that I think has been around?
In the build for libc I see that the math functions are commented out. I need the atan2f function which are in there. Can I just add that back or is there a reason those are not included?
@Rayman said:
@n_ermosh I downloaded libp2.a from Zemon's CI server using your link and it compiled.
But, my nearly empty program produced a 521 kB elf file.
So, maybe it's still in that one?
Also, it seems I need to compile loadp2.exe as well.
Is this the same loadp2 that I think has been around?
I'm running tests on this right now. A simple program without p2db linked appears to be 512kb but loads super fast, so I don't think it's actually loading those sections.
@iseries said:
In the build for libc I see that the math functions are commented out. I need the atan2f function which are in there. Can I just add that back or is there a reason those are not included?
Mike
I commented them out because I never tried building them, feel free to uncomment and try building. FYI I've moved the libc build to cmake so be consistent with everything else
Comments
I changed them on purpose--the locations loadp2 uses will intersect with the entry routine. So if you use the patching in loadp2 it will not function properly. So to use the locations from loadp2, we'd need to change how startup works to add a function to jump over those locations. In fact, looking at it now, even my locations intersect if you patch it in... so maybe the best course of action is to move the entry function, and make the instruction at 0x00 just jump to that function
As an aside, where do those addresses come from? Convention from P1? Is there a specific reason we need to keep those values at those addresses, or can we leave it up to compiler implementation to define? It would make patching when loading a bit more difficult, because you'd need to specify where to patch the values, but adds flexibility.
Okay it was actually pretty simple. Something like this: https://github.com/ne75/p2llvm/blob/new_startup/libp2/lib/crt0.c. lets merge your changes to set clkmode on startup into this branch to change it all at once in mater
@iseries I'm not finding libp2.a ... Where should it be?
hummm, don't see any code at those locations?
Seems to work fine for me.
Mike
Dave Hein came up with those numbers who wrote the loadp2 code. Chip had some numbers as well but I don't think they match. And yes, the P1 had similar items.
It looks like you removed the debug init code (https://github.com/iseries1/p2llvm/blob/master/libp2/lib/crt0.c#L33-L43), so yours is okay, but if you leave the debug code in, it makes the
__entry
function extend up to 0x24.Also, to set the patched values, you should be able to just call
_clkset
instead of using a bunch of inline assembly, like you have here https://github.com/iseries1/p2llvm/blob/master/libp2/lib/crt0.c#L72-L83@Rayman ,
When I loaded my project I had 555 items, you only have 400?
What path did you use to build your P2LLVM code?
I made a folder called "opt" and then "p2llvm". In there you put bin, lib, libc, libp2 folders.
Mike
Where does Chip put his debug code? He uses similar addresses.
Mike
Here's what opt looks like (see pic). Is this right?
Just tried to build a cpp file and got this:
C:\opt\p2llvm\llvm-project\build\Release>clang --target=p2 -Wl,--gc-sections -Wl,--print-gc-sections -o test.elf test.o
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lp2
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)
Also, the solution does show 555 projects...
Not sure, but hubset to enable cog 0 debugging needs to be called before coginit for cog 0, so it needs to happen in
__entry
. Actual debugger code lives in debug space at the end of RAM@iseries VS Solution looks like this:
@Rayman ,
Looks like you have everything. You need to build libc.a and libp2.a before you can compile.
My github environment is located somewhere else so I just copy bin, lib over to this location.
I have a startup shortcut that adds bin to my path so I can compile with a special bat file.
Mike
@iseries How do I build libc.a and libp2.a ?
Looks like I was supposed to do "cmake libc" at some point?
@Rayman ,
That's a good one. My Cmake does not work for that so I used make instead. There are some leftover make files in each folder that when you run make it will create a build folder and put the two archives in it. Those need to be copied out to the p2llvm folder.
Don't know if you can get cmake to work for you but you can also try that. cd to libp2 and run cmake I think.
I could also give you a copy of libc.a and libp2.a but these would be custom build and not the official versions, but I know they work.
Mike
@iseries If you can just give me these files, that would be great. I don't think I have "make" installed...
I'm guessing I could build these with make on a Mac, right? Would those then be able to be used in Windows?
you can download a build off of Zemon's CI server here: https://ci.zemon.name/repository/download/P2llvm_LlvmMacosArm/14773:id/p2llvm-macos-arm64-be79cd8705edcbb3b3e2b4e1d5f4927500c77573.tar.gz?guest=1 and pull out the built libraries from there.
Yeah that would work, and for mac or linux, you don't need to build from scratch--we've got it building for linux and mac (for both arm and x86)
@Rayman ,
Please note that programs that are compiled with libp2.a have debug code in them and will generate bloated programs (512k) in size. This does not represent the program size just that in order to load them as one file they need to load the dead space as well.
I disabled the debug code and my compiles are around 25k for a simple program.
Mike
@iseries I was just about to ask about that!
How do you disable the debug code?
If you use the downloaded build, libp2.a no longer contains debug code--that now lives in libp2db.a, so if you don't link p2db, no debugging code should be included.
Only thing is that I think it will still try to load 0's for that section of code, which is at the end of ram, so if you first use objcopy to convert the elf to load a bin, it will load significantly faster cause it will ignore all of that.
@n_ermosh I downloaded libp2.a from Zemon's CI server using your link and it compiled.
But, my nearly empty program produced a 521 kB elf file.
So, maybe it's still in that one?
Also, it seems I need to compile loadp2.exe as well.
Is this the same loadp2 that I think has been around?
In the build for libc I see that the math functions are commented out. I need the atan2f function which are in there. Can I just add that back or is there a reason those are not included?
Mike
I'm running tests on this right now. A simple program without p2db linked appears to be 512kb but loads super fast, so I don't think it's actually loading those sections.
I commented them out because I never tried building them, feel free to uncomment and try building. FYI I've moved the libc build to cmake so be consistent with everything else
Yes, I saw you were changing that to cmake.
If you use loadp2 to load the programs it runs at 2,000,000 baud so even the largest program will load fast. Trust me it's loading the whole shebang.
Mike
I tried using FlexProp to load the .elf file by renaming to .bin2. It took a very long time to load...
Now, trying to add something so that I can tell if it's actually working...
Tried this:
But, it gives errors on pinnot and waitms... How can I do things like this?
See https://github.com/ne75/p2llvm/blob/master/libp2/include/propeller2.h for the various macros and functions to control hardware. in your case, I'd do:
Okay... I will look into this today, time to solve this once and for all