Here's a new version of loadp2.c that incorporates MainLoader1.spin2. It sets up the oscillator, waits 10 ms, and then enables the oscillator. For 80MHz, the mode should be 010c1f04.
UPS delivered my board about a half hour ago. I am able to run most of the p2gcc test programs. I'm using the version of loadp2 that I posted in my previous post. I load the programs as follows:
loadp2 -v -t -m 010c1f08 hello.bin
The mode value of 010c1f08 sets the board to 80MHz so that my serial code runs at the right baud rate. The following programs run without any problems:
bas chess dry fibo fft_bench hello malloctest prime xxtea test7
The blink program doesn't work correctly, and fsrwtest and filetest do not mount the SD card. I'll look at them to try to figure out what's wrong.
The blink program works with P32-P37, which aren't displayed on the P2 Eval board. So it's probably working OK, but I can't see the those bits on the board.
EDIT: I change blink to us P56-P59, and it's working fine.
Still not printing anything in loadp2's terminal. I'm reading from the beginning of the thread to see if I missed anything.
You uploaded two files above - loadp2.c and MainLoader1.spin2. I don't see any reference to that file throughout the codebase, including in your newly uploaded loadp2.c. Am I missing something there?
The loader needs to know the frequency, so the -f option must be used. The C serial driver assumes 80MHz, so the baud rate is proportional to the clock frequency, which is why I had to specify a higher baud rate. Eventually I'll clean this up so that only a clock rate needs to be specified. I should be able to detect FPGA versus silicon so that the mode is set up properly.
You uploaded two files above - loadp2.c and MainLoader1.spin2. I don't see any reference to that file throughout the codebase, including in your newly uploaded loadp2.c. Am I missing something there?
You uploaded two files above - loadp2.c and MainLoader1.spin2. I don't see any reference to that file throughout the codebase, including in your newly uploaded loadp2.c. Am I missing something there?
You uploaded two files above - loadp2.c and MainLoader1.spin2. I don't see any reference to that file throughout the codebase, including in your newly uploaded loadp2.c. Am I missing something there?
You uploaded two files above - loadp2.c and MainLoader1.spin2. I don't see any reference to that file throughout the codebase, including in your newly uploaded loadp2.c. Am I missing something there?
The content of a compiled MainLoader1.spin2 is included previously in loadp2.c...
char *MainLoader =
#if 0
" 00 1e 60 fd 13 00 88 fc 20 7e 65 fd 24 08 60 fd 24 28 60 fd 1f 20 60 fd 08 06 dc fc 40 7e 74 fd$
#else
" 00 26 60 fd 86 01 80 ff 1f 80 66 fd 03 26 44 f5 00 26 60 fd 17 00 88 fc 20 7e 65 fd 24 08 60 fd$
#endif
Thanks - that makes sense now.
I've only gotten loadp2 to work on a Win 10 VM... And, only to load binaries that were built by PNut. I still need to test (on Win 10) loading binaries built from fastspin, with the most-recent notes about setting mode & frequency as loadp2 params...
Have not been able to use loadp2 successfully on Linux or macOS, so far.
I've only gotten loadp2 to work on a Win 10 VM... And, only to load binaries that were built by PNut. I still need to test (on Win 10) loading binaries built from fastspin, with the most-recent notes about setting mode & frequency as loadp2 params...
Have not been able to use loadp2 successfully on Linux or macOS, so far.
dgately,
I also need to get loadp2 working on ubuntu natively.
You may want to read my post in P2 Newbie Discussion (about 30 mins ago), may solve your problem.
I tried loadp2 on my ubuntu system, and it doesn't work for me either. I tried changing wait times, and I fiddled with the hwreset routine, but it still doesn't run.
I was also hoping to detect between the FPGA version and the silicon version, but it appears that they both return Prop_Ver A. Is there anyway to distinguish between the two?
Just curious, re: your last post...what system were you running on in the previous posts in this thread, where you were able to successfully load? The $ prompt gives the impression it was unix-like?
I was running under Cygwin. In theory, the code should compile fine under MinGW and run under Windows. I generally don't test out MinGW/Windows until I'm ready to send out an exe file.
I'll be posting an update soon with Windows executables once I finished adding some changes to loadp2 so it supports both the FPGA and the P2 silicon.
I was also hoping to detect between the FPGA version and the silicon version, but it appears that they both return Prop_Ver A. Is there anyway to distinguish between the two?
That seems an oversight, should be easy to fix on next steps.
TAQOZ takes 240ms to enable, so that's a bit slow for checks.
There is the Prop_Clk command - what does that do different on FPGA vs Silicon ? IIRC it is only 2 choices 20M/80M on FPGA ?
So maybe switch to rcslow, and then '> Prop_Ver... - a reply at high baud rates is FPGA ?
@DavidZemon has two versions of PropGcc on his Buildserver. GCC4 and GCC5.
Which one I should install to use P2gcc on a P2-EVAL?
Mike
Please keep in mind that "GCC5" actually refers to GCC6 now... I'm avoiding a rename because I don't want a million links that are spread across the forums to suddenly stop working.
I was also hoping to detect between the FPGA version and the silicon version, but it appears that they both return Prop_Ver A. Is there anyway to distinguish between the two?
I was wrong about the version returned by the FPGA. It returns version B. So I can auto-detect FPGA versus silicon. I've already modified loadp2 to allow specifying FPGA or silicon. So I'll change it to use the version, and an option can be used to override it.
So now the only thing that needs to be specified is the clock frequency. loadp2 will then generate the appropriate mode value and user baud rate. If the clock rate isn't specified it will default to 80MHz. So a load command can be as simple as
loadp2 -t hello.bin
and the loader will detect FPGA versus silicon, and generate the correct clock mode and user baud rate. I've also added a -SINGLE option that will use a single stage loader. The user program will have to configure the clock itself.
I was also hoping to detect between the FPGA version and the silicon version, but it appears that they both return Prop_Ver A. Is there anyway to distinguish between the two?
I was wrong about the version returned by the FPGA. It returns version B. So I can auto-detect FPGA versus silicon.
That's easier.
Thinking ahead, should the next FPGA return version C (as it is quite different in features), and then next silicon rev reports Version D, so the software checks work across all releases.
I then will install gcc5 from @DavidZemon which is gcc6 and hopefully the version used to start P2 work on.
There is something irritating me, why 80Mhz?
The FPGA did run at 80Mhz, but the silicon starts at RCFAST, so ~18-23Mhz and can go way faster as the FPGA.
Pnut tells me that my EVAL runs at 80Mhz. Why? Shouldn't Version B show 80Mhz but Version A (the silicon) show something like 120 or 180 or even 360?
confused
Mike
That's just software catching up.
FPGA was 20 / 80 MHz so that was where all software testing was done, and how SW was coded.
Now real P2 silicon exists, the SW has to catch up to the various XTALS and Boards, and allow users to define the clock settings.
But putting a '80Mhz' there makes no sense. P2 was projected at 120 (160?) and is running even faster. The 80 is a remainder of the FPGA and has nothing to do with the actual silicon.
I don't know why PNut shows 80MHz, but it is the default for loadp2. A program that was developed for the FPGA can run without change on the silicon at 80MHz. Of course, the silicon can run at faster speeds, but a lot of code can be checked out at 80MHz to make sure it is logically correct.
Comments
EDIT: I change blink to us P56-P59, and it's working fine.
maybe di/do, depending on that code perspective...
the eval sd card pinout is
58 ... miso
59 ... mosi
60 ... cs
61 ... clk
You uploaded two files above - loadp2.c and MainLoader1.spin2. I don't see any reference to that file throughout the codebase, including in your newly uploaded loadp2.c. Am I missing something there?
The loader needs to know the frequency, so the -f option must be used. The C serial driver assumes 80MHz, so the baud rate is proportional to the clock frequency, which is why I had to specify a higher baud rate. Eventually I'll clean this up so that only a clock rate needs to be specified. I should be able to detect FPGA versus silicon so that the mode is set up properly.
This'll be it (In loadp2.c), see last line:
if (verbose) printf("Loading %s - %d bytes\n", fname, size); hwreset(); msleep(50); tx((uint8_t *)"> Prop_Hex 0 0 0 0", 18); tx((uint8_t *)MainLoader, strlen(MainLoader));david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ cat Makefile export PATH := $(PROPGCC_PREFIX)/bin:$(PATH) run-%: %.bin @echo --- LOADING $< --- loadp2 -v -t -p /dev/ttyUSB0 -m 010c1f08 $< %.bin: %.c @echo --- COMPILING $< --- bash p2gcc -v -o $@ $< clean: rm -f *.o *.bin david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ cat hello.c #include <stdio.h> #include <propeller.h> void main(void) { int i; for (i = 1; i <= 10; i++) { waitcnt(CNT+12000000); printf("Hello World - %d\n", i); } printf("Goodbye\n"); } david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ make clean run-hello rm -f *.o *.bin --- COMPILING hello.c --- bash p2gcc -v -o hello.bin hello.c propeller-elf-gcc -mcog -Os -m32bit-doubles -S hello.c s2pasm -p/home/david/reusable/software/p2gcc/lib/prefix.spin2 hello p2asm -c -o hello.spin2 p2link /home/david/reusable/software/p2gcc/lib/prefix.o -v -o hello.bin hello.o /home/david/reusable/software/p2gcc/lib/stdio.a /home/david/reusable/software/p2gcc/lib/stdlib.a /home/david/reusable/software/p2gcc/lib/string.a Found offset of 12 for symbol ___files of type 04 at location b14 --- LOADING hello.bin --- loadp2 -v -t -p /dev/ttyUSB0 -m 010c1f08 hello.bin Loading hello.bin - 2548 bytes hello.bin loaded [ Entering terminal mode. Press ESC to exit. ] rm hello.bin david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$Maybe I'm doing something wrong when building p2gcc? I tried starting over from scratch:
Still nothing in loadp2's terminal.
Thanks - that makes sense now.
Have not been able to use loadp2 successfully on Linux or macOS, so far.
dgately,
I also need to get loadp2 working on ubuntu natively.
You may want to read my post in P2 Newbie Discussion (about 30 mins ago), may solve your problem.
I was also hoping to detect between the FPGA version and the silicon version, but it appears that they both return Prop_Ver A. Is there anyway to distinguish between the two?
Just curious, re: your last post...what system were you running on in the previous posts in this thread, where you were able to successfully load? The $ prompt gives the impression it was unix-like?
Thanks,
Jesse
I'll be posting an update soon with Windows executables once I finished adding some changes to loadp2 so it supports both the FPGA and the P2 silicon.
TAQOZ takes 240ms to enable, so that's a bit slow for checks.
There is the Prop_Clk command - what does that do different on FPGA vs Silicon ? IIRC it is only 2 choices 20M/80M on FPGA ?
So maybe switch to rcslow, and then '> Prop_Ver... - a reply at high baud rates is FPGA ?
Which one I should install to use P2gcc on a P2-EVAL?
Mike
Please keep in mind that "GCC5" actually refers to GCC6 now... I'm avoiding a rename because I don't want a million links that are spread across the forums to suddenly stop working.
So now the only thing that needs to be specified is the clock frequency. loadp2 will then generate the appropriate mode value and user baud rate. If the clock rate isn't specified it will default to 80MHz. So a load command can be as simple as and the loader will detect FPGA versus silicon, and generate the correct clock mode and user baud rate. I've also added a -SINGLE option that will use a single stage loader. The user program will have to configure the clock itself.
I then will install gcc5 from @DavidZemon which is gcc6 and hopefully the version used to start P2 work on.
There is something irritating me, why 80Mhz?
The FPGA did run at 80Mhz, but the silicon starts at RCFAST, so ~18-23Mhz and can go way faster as the FPGA.
Pnut tells me that my EVAL runs at 80Mhz. Why? Shouldn't Version B show 80Mhz but Version A (the silicon) show something like 120 or 180 or even 360?
confused
Mike
That's easier.
Thinking ahead, should the next FPGA return version C (as it is quite different in features), and then next silicon rev reports Version D, so the software checks work across all releases.
That's just software catching up.
FPGA was 20 / 80 MHz so that was where all software testing was done, and how SW was coded.
Now real P2 silicon exists, the SW has to catch up to the various XTALS and Boards, and allow users to define the clock settings.
So again why 80?
Mike