Hi David, how far off are we getting a p2load data to address x, and don't reset/run can you tell I'm eager haha
Loving not only having some P2 kit, but especially loving having some time to play with it too!
Hi David, how far off are we getting a p2load data to address x, and don't reset/run can you tell I'm eager haha
Loving not only having some P2 kit, but especially loving having some time to play with it too!
I'll work on it again late tonight. Unfortunately, I have a previous commitment for early this evening.
Do you by any chance have some code that comes in multiple pieces that I can use for testing? Nothing produced by PropGCC requires this scatter-load feature.
I will start a new thread to discuss reserved hub usage. I am not confident we will get agreement as the naysayers have always derailed the P1 discussions in the past.
BTW I am happy to agree to Bill's latest use:
$E80-$E8F: system
$E90-$FFF: 23 mailboxes
But I would like to use the 1st mailbox (or the system) to hold flags to indicate the mailbox is claimed/used/allocated.
P2load:
David: From all the above discussion, it seems that you are going to implement a loader for multiple files. Am I correct in understanding / or can you implement?...
Resets the P2
Load the second stage bootloader (postedit)
Loads each file with the following options:
the skip option -s [$xxxxx] (default = 0) - skips n bytes at the beginning of the binary file
the load option -h [$xxxxx] (default = $01000) - loads to hub address
Starts by performing COGINIT for COG0 using:
the go option -g [$xxxxx] (default = $01000) -coginit cog0 at hub address
would be nice to have an alternative option "-g monitor" to call the rom monitor instead
You will note I have added an optional address, as not only do I think this is useful, it is required for what I need to do in testing. I also think it will be useful beyond this where we want to include other code blocks. Sort of like a linker without needing to link (or we code with other modules with constants).
I am not fussed with -g, -h, -s or whatever you decide to use.
I am only interested in loading binary files (pnut .obj files). I am not interested in using the slower Rom monitor loading. That can be done separately, especially if you can add the option to call the rom monitor. We can always get around this easily by adding an extra file that only has the monitor calling code, and starting it. Then a separate program can load using the monitor. Andy may have already done this with prop2terminal (see sticky)
I will start a new thread to discuss reserved hub usage. I am not confident we will get agreement as the naysayers have always derailed the P1 discussions in the past.
BTW I am happy to agree to Bill's latest use:
$E80-$E8F: system
$E90-$FFF: 23 mailboxes
But I would like to use the 1st mailbox (or the system) to hold flags to indicate the mailbox is claimed/used/allocated.
P2load:
David: From all the above discussion, it seems that you are going to implement a loader for multiple files. Am I correct in understanding / or can you implement?...
Resets the P2
Loads each file with the following options:
the skip option -s [$xxxxx] (default = 0) - skips n bytes at the beginning of the binary file
the load option -h [$xxxxx] (default = $01000) - loads to hub address
Starts by performing COGINIT for COG0 using:
the go option -g [$xxxxx] (default = $01000) -coginit cog0 at hub address
would be nice to have an alternative option "-g monitor" to call the rom monitor instead
You will note I have added an optional address, as not only do I think this is useful, it is required for what I need to do in testing. I also think it will be useful beyond this where we want to include other code blocks. Sort of like a linker without needing to link (or we code with other modules with constants).
I am not fussed with -g, -h, -s or whatever you decide to use.
I am only interested in loading binary files (pnut .obj files). I am not interested in using the slower Rom monitor loading. That can be done separately, especially if you can add the option to call the rom monitor. We can always get around this easily by adding an extra file that only has the monitor calling code, and starting it. Then a separate program can load using the monitor. Andy may have already done this with propload.
This is basically correct except that there is a step 2a that downloads and starts the second-stage loader. The P2 ROM bootloader is not able to load more than 2K bytes so I have to use a second-stage loader to load everything else. This is hidden from the user so maybe it doesn't need to be included in the sequence.
This is basically correct except that there is a step 2a that downloads and starts the second-stage loader. The P2 ROM bootloader is not able to load more than 2K bytes so I have to use a second-stage loader to load everything else. This is hidden from the user so maybe it doesn't need to be included in the sequence.
This is basically correct except that there is a step 2a that downloads and starts the second-stage loader. The P2 ROM bootloader is not able to load more than 2K bytes so I have to use a second-stage loader to load everything else. This is hidden from the user so maybe it doesn't need to be included in the sequence.
Thanks heaps David. Yes I keep forgetting about the 2 stage loader. I will edit my post to include it for future reference.
we could use the 3rd long in the system box, with a simple bit flag to indicate "in use"
ie $E88 would be the mailbox-in-use word
bit 0 always set (to inidicate system box is always in use)
bit 1 - bit 23 would be '1' when mailbox 1 .. 23 is in use
Bits 24-32 would be reserved for now, but later could be used for something else.
CLKMODE uses 9 bits (8..0) leaving precisely 23 bits.
So, default for bare metal is all these 23 bits =0 which indicates all used. The bare metal can start their programs as $E82 if they wish.
When we reserve the 23 mailboxes we set these 23 bits =1 which indicates all available for use, and when claimed/used those respective bits are cleared.
Sounds good. I like sharing CLKMODE - you saved us all a long!
$E88 start for "bare metal" (second stage loader; rom loader i think loads boot loader at $E80 - which is why I initially wanted CLKFREQ and CLKMODE just before $1000)
CLKMODE uses 9 bits (8..0) leaving precisely 23 bits.
So, default for bare metal is all these 23 bits =0 which indicates all used. The bare metal can start their programs as $E82 if they wish.
When we reserve the 23 mailboxes we set these 23 bits =1 which indicates all available for use, and when claimed/used those respective bits are cleared.
Thanks! I'm back on the job and will try to get this loader working this evening.
I'm not going to be able to get this done tonight I'm afraid. I wrote all of the code but it doesn't work. :-)
I'm not sure if this is a bug in my second-stage loader or a bug in gas that is assembling it wrong. Ugh. I'll have to look at it again tomorrow.
No worries ;D
Just out of interest, could you not use PNut to make the second stage loader, as that would assemble it correctly?
I could but then I would only be able to build p2load on Windows. I did this when I first started writing p2load but switched to gas so that I could build on all platforms. I guess I should check with Roy to see how soon we can expect the PASM part of his his Spin compiler to be ported to P2.
I could but then I would only be able to build p2load on Windows. I did this when I first started writing p2load but switched to gas so that I could build on all platforms. I guess I should check with Roy to see how soon we can expect the PASM part of his his Spin compiler to be ported to P2.
Did you know you can wine PNut, it builds files, but I couldn't get it to download, which would be ok, as you don't want that part.
Did you know you can wine PNut, it builds files, but I couldn't get it to download, which would be ok, as you don't want that part.
GAS needs to work anyway and I'm not even sure that is the problem at this point. This isn't very complicated code but execution seems to reach a point multiple times that it shouldn't reach more than once and never reach a point that it should reach once. I may have direct vs. indirect jmps wrong. The code is attached if you want to see if you can see where I'm going wrong. The download completes but the program doesn't run correctly. Please don't laugh too hard at my PASM code though! :-)
GAS needs to work anyway and I'm not even sure that is the problem at this point. This isn't very complicated code but execution seems to reach a point multiple times that it shouldn't reach more than once and never reach a point that it should reach once. I may have direct vs. indirect jmps wrong. The code is attached if you want to see if you can see where I'm going wrong. The download completes but the program doesn't run correctly. Please don't laugh too hard at my PASM code though! :-)
Edit: The place it reaches multiple times is the code at cmd_start. The place it never reaches is the code at do_cmd1.
By the way, the reason I think it is getting to cmd_start more than once is that I modified the code like this to turn on a different LED each time it passes through that code.
Eight LEDs come on before the COG resets and tries to start the loaded program. The p2load program only sends one command packet. Every other packet should contain data.
By the way, the reason I think it is getting to cmd_start more than once is that I modified the code like this to turn on a different LED each time it passes through that code.
Eight LEDs come on before the COG resets and tries to start the loaded program. The p2load program only sends one command packet. Every other packet should contain data.
Ugh!!! Never mind. I'm an idiot. I figured out what's happening. The fact that only 8 LEDs came on is what gave me the clue. I'm updating the wrong state variable. I should have this fixed shortly. Sorry!!!!
The idea is that p2load first sends an 8 byte packet that contains the load address and byte count. It then sends as many data packets as needed to transfer that many bytes of data and then loops back looking for another 8 byte addr/count packet. This should allow the loader to scatter-load data at various addresses in hub memory before starting the program.
Comments
Loving not only having some P2 kit, but especially loving having some time to play with it too!
pm me your email addy.
BTW I am happy to agree to Bill's latest use:
$E80-$E8F: system
$E90-$FFF: 23 mailboxes
But I would like to use the 1st mailbox (or the system) to hold flags to indicate the mailbox is claimed/used/allocated.
P2load:
David: From all the above discussion, it seems that you are going to implement a loader for multiple files. Am I correct in understanding / or can you implement?...
- Resets the P2
- Load the second stage bootloader (postedit)
- Loads each file with the following options:
- the skip option -s [$xxxxx] (default = 0) - skips n bytes at the beginning of the binary file
- the load option -h [$xxxxx] (default = $01000) - loads to hub address
- Starts by performing COGINIT for COG0 using:
- the go option -g [$xxxxx] (default = $01000) -coginit cog0 at hub address
- would be nice to have an alternative option "-g monitor" to call the rom monitor instead
You will note I have added an optional address, as not only do I think this is useful, it is required for what I need to do in testing. I also think it will be useful beyond this where we want to include other code blocks. Sort of like a linker without needing to link (or we code with other modules with constants).I am not fussed with -g, -h, -s or whatever you decide to use.
I am only interested in loading binary files (pnut .obj files). I am not interested in using the slower Rom monitor loading. That can be done separately, especially if you can add the option to call the rom monitor. We can always get around this easily by adding an extra file that only has the monitor calling code, and starting it. Then a separate program can load using the monitor. Andy may have already done this with prop2terminal (see sticky)
ie $E88 would be the mailbox-in-use word
bit 0 always set (to inidicate system box is always in use)
bit 1 - bit 23 would be '1' when mailbox 1 .. 23 is in use
Bits 24-32 would be reserved for now, but later could be used for something else.
This is basically correct except that there is a step 2a that downloads and starts the second-stage loader. The P2 ROM bootloader is not able to load more than 2K bytes so I have to use a second-stage loader to load everything else. This is hidden from the user so maybe it doesn't need to be included in the sequence.
It is not necessary to user to see it --- But after complete load it need stop running and give control to Monitor else COG specified in start flag.
CLKMODE uses 9 bits (8..0) leaving precisely 23 bits.
So, default for bare metal is all these 23 bits =0 which indicates all used. The bare metal can start their programs as $E82 if they wish.
When we reserve the 23 mailboxes we set these 23 bits =1 which indicates all available for use, and when claimed/used those respective bits are cleared.
I will start that thread now
$E88 start for "bare metal" (second stage loader; rom loader i think loads boot loader at $E80 - which is why I initially wanted CLKFREQ and CLKMODE just before $1000)
Here's an example file...
load the testcard.bin to $8000
then load the program, I've attached the source, and object and bin file.
Let me know how you get on.
Cheers,
Jim.
MyProp2Code.zip
I'm not sure if this is a bug in my second-stage loader or a bug in gas that is assembling it wrong. Ugh. I'll have to look at it again tomorrow.
Just out of interest, could you not use PNut to make the second stage loader, as that would assemble it correctly?
Did you know you can wine PNut, it builds files, but I couldn't get it to download, which would be ok, as you don't want that part.
loader.s
Edit: The place it reaches multiple times is the code at cmd_start. The place it never reaches is the code at do_cmd1.
Will look later, and let you know if I find anything.
receive call #rx jmp rcv_state do_soh cmp x, #SOH wz if_z mov rcv_state, #do_len_hi jmp #receive 'byte done, receive next byte rcv_state res 1cmd_start mov payload_state, #do_cmd0 mov cmd0, #0 mov cmd_cnt, #4 setp led add led, #1Eight LEDs come on before the COG resets and tries to start the loaded program. The p2load program only sends one command packet. Every other packet should contain data.but I did have to set up a COM1 mapping to /dev/ttyUSB0 for wine
Edit: For any of you who are following this second-stage loader saga, here is the corrected source:
loader.s
The idea is that p2load first sends an 8 byte packet that contains the load address and byte count. It then sends as many data packets as needed to transfer that many bytes of data and then loops back looking for another 8 byte addr/count packet. This should allow the loader to scatter-load data at various addresses in hub memory before starting the program.
Now I know who one send snow to me!
@Sapieha, haha yeah, sorry bud!
No problem.
Only problem that Spring are already next one month to late in my end of country