Will do. I had Chip review the monitor doc. I figure this time we can get this stuff done as we build basic tools. There is time to sort out where it lives. IMHO, that needs to happen, and I don't care where.
Will do. I had Chip review the monitor doc. I figure this time we can get this stuff done as we build basic tools. There is time to sort out where it lives. IMHO, that needs to happen, and I don't care where.
That all works for me. If somebody reads the thing, they just need to be able to get the program. I linked to the forum for Ariba's Prop Terminal. There is a thread he updates, and that's where it lives. No worries. I just need to know what the plan is, and would prefer few updates, that's all.
Are people generally happy with the way p2load works at this point? Are there any issues that still need addressing or can I consider it stable for the moment?
I've never noticed. Will go look since you mentioned it though.
The problem with regular threads is they fall off the top over time and even google search is useless without terms.
If they fall off the top page I assume they will still be accessible through the links in the top sticky post won't they? Or do they eventually get deleted if they aren't accessed often enough?
Are people generally happy with the way p2load works at this point? Are there any issues that still need addressing or can I consider it stable for the moment?
It is working great for me David. Many thanks. I have been giving it a workout but I am only loading 1 file for now.
I am trying to maintaint the first post in the sticky to anything new and relevant. If you need something updated there, preference is to detail it in a post to that thread, and I will update a summary on the first post. I will also link to a thread if relevant. If I do miss something, pm me.
I started a thread for P2 Drivers & Tools where you can add these references. I need to update the sticky with a link to this thread once it gains traction.
If they fall off the top page I assume they will still be accessible through the links in the top sticky post won't they? Or do they eventually get deleted if they aren't accessed often enough?
They never get deleted, just relegated further down the list according to the date of the last post.
I've updated the top post with a new version that supports the -T option to enter a PST-compatible terminal mode. This can be used instead of -t if you need \r translated to \r\n. So far, that is the only difference between -t and -T.
I've updated the top post with a new version that supports the -T option to enter a PST-compatible terminal mode. This can be used instead of -t if you need \r translated to \r\n. So far, that is the only difference between -t and -T.
I've updated the top post with a new version that supports the -T option to enter a PST-compatible terminal mode. This can be used instead of -t if you need \r translated to \r\n. So far, that is the only difference between -t and -T.
Fantastic work, thanks David - Works great and with the dos box I can scroll back. I have just updated my batch file to use -T mode and -b 115200.
I noticed the first time your code failed to recognise the board. I have this occasionally on PST and other software on P1. PropTool always seems to find the board though. There must be something subtle in the timing. This is only the first time after the board is plugged in to the USB, so it is definately not a problem. I just re-ran p2load and it found the board.
Fantastic work, thanks David - Works great and with the dos box I can scroll back. I have just updated my batch file to use -T mode and -b 115200.
I noticed the first time your code failed to recognise the board. I have this occasionally on PST and other software on P1. PropTool always seems to find the board though. There must be something subtle in the timing. This is only the first time after the board is plugged in to the USB, so it is definately not a problem. I just re-ran p2load and it found the board.
Out of curiousity, why are you using 115200? Is 230400 unreliable for you? Should I change the default back to 115200?
By the way, the code I'm using to detect the P2 is a translation of Chip's Pascal code so I would think it would work as well as PNut. Of course, maybe I made an error in the translation.
Out of curiousity, why are you using 115200? Is 230400 unreliable for you? Should I change the default back to 115200?
By the way, the code I'm using to detect the P2 is a translation of Chip's Pascal code so I would think it would work as well as PNut. Of course, maybe I made an error in the translation.
I universally use 115200 where I can. My code has the baud set in the CON section - so it's easy enough to change. If my loads took too long I would switch, but it is not a problem for me currently. Since I call p2load via a batch file, it is just as easy to add the -b 115200 in. Others may have a different opinion. In fact my bat file was still using -c 0,1000:0 instead of -h (I had tried it manually for you).
I cannot say if pnut has always recognised the DE0 or not - just cannot recall. I do know that sometimes PST does not recognise the port first up, and I load PropTool and F7 to identify the port. PropTool always seems to work unless the USB breaks in windoze and that often requires a windoze reboot - not often, but it happens. Don't worry about it - I will keep an eye on it and see if there is any specifics in this, or just an occasional glitch.
I universally use 115200 where I can. My code has the baud set in the CON section - so it's easy enough to change. If my loads took too long I would switch, but it is not a problem for me currently. Since I call p2load via a batch file, it is just as easy to add the -b 115200 in. Others may have a different opinion. In fact my bat file was still using -c 0,1000:0 instead of -h (I had tried it manually for you).
Okay, I'll wait to hear from others. It seems like someone was looking for a faster load time but maybe we'd be better sticking with 115200 as a default. At least that matches propeller-load.
I cannot say if pnut has always recognised the DE0 or not - just cannot recall. I do know that sometimes PST does not recognise the port first up, and I load PropTool and F7 to identify the port. PropTool always seems to work unless the USB breaks in windoze and that often requires a windoze reboot - not often, but it happens. Don't worry about it - I will keep an eye on it and see if there is any specifics in this, or just an occasional glitch.
I've seen the failure to detect the P2 but I think it always happened to me if I tried too soon after plugging in the USB cable. If I wait a second or so I think it always works. I haven't done a scientific test though. If anyone wants to look over my serial port code they're welcome to. I'd be happy to have someone suggest a fix to make it more reliable.
When the ROM loader starts, it fires up a COG with the HMAC/SHA-256 engine. Once it has completed the authentication/verification, it shuts the COG back down. However, it seems to me that the second-stage loader is going to want to do the same authentication/verification of the remaining code that it loads. Obviously, it could just start the engine back up again, but I am wondering if the engine could just be left running by the first-stage loader. This would provide a small start-up performance boost and save a few instructions in the second-stage loader. The ROM loader would still be the same size because the COGSTOP would likely be moved to the section where authentication failed.
The workflow is intended as thus:
ROM loads boot loader
ROM authenticates boot loader
boot loader runs
boot loader reads SPI flash contents into main memory
boot loader uses AES-128 in CBC mode to decrypt memory contents
boot loader chain loads to program in memory
There is little value in authenticating un-encrypted code, thus the SHA-256 engine shuts down. The data is right there in ROM, so you can launch it again if you want.
For all cases where authentication and encryption are unneeded, you simply leave the key all zeros, but as soon as you need to authenticate, you should also be encrypting the code too.
As for CBC vs other vector protocols, don't fret, CBC is used in A LOT of hardware/network security protocols, and there are no demonstrable exploits against it.
I've just updated the top message in this thread with a new version of p2load that supports some new options. First, you can now specify which COG to run the main program in using the following syntax:
[ -r n, ] run program in COG n
[ -r n,addr[:param] ] run program in COG n from addr with parameter param
The first just sets the COG in which to run the main program. The second also allows you to specify the address of the COG image and the parameter to pass to coginit.
I've also added some options to allow you to write data to flash:
[ -f file,faddr ] write contents of file to flash at faddr
[ -f faddr,haddr,count ] write count bytes of hub data at haddr to flash at faddr
The first writes the contents of a file to flash at the specified address. The second writes data from hub memory to flash.
Finally, I've added a way to write a bootable image to the flash. This makes it possible to have a program boot on reset without having to download it each time.
[ -w ] write a bootable image to flash
I now have Baggers' Fire demo running out of flash on my DE2-115 board! :-)
In addition to being attached to the top message of this thread this version is also checked into Google Code in the p2test branch.
I've just updated the top message in this thread with a new version of p2load that supports some new options. First, you can now specify which COG to run the main program in using the following syntax:
[ -r n, ] run program in COG n
[ -r n,addr[:param] ] run program in COG n from addr with parameter param
The first just sets the COG in which to run the main program. The second also allows you to specify the address of the COG image and the parameter to pass to coginit.
I've also added some options to allow you to write data to flash:
[ -f file,faddr ] write contents of file to flash at faddr
[ -f faddr,haddr,count ] write count bytes of hub data at haddr to flash at faddr
The first writes the contents of a file to flash at the specified address. The second writes data from hub memory to flash.
Finally, I've added a way to write a bootable image to the flash. This makes it possible to have a program boot on reset without having to download it each time.
[ -w ] write a bootable image to flash
I now have Baggers' Fire demo running out of flash on my DE2-115 board! :-)
In addition to being attached to the top message of this thread this version is also checked into Google Code in the p2test branch.
David: I noticed a minor bug in P2Load. If the .obj file is not found, the program reports that the port and P2 is not found rather than the file is not found.
David: I noticed a minor bug in P2Load. If the .obj file is not found, the program reports that the port and P2 is not found rather than the file is not found.
Thanks for letting me know about that. I'll check into it.
David: I noticed a minor bug in P2Load. If the .obj file is not found, the program reports that the port and P2 is not found rather than the file is not found.
Can you give me an example of this. I just tried this simple example and it complained about the missing file.
david-betzs-macbook-pro:p2load dbetz$ p2load foo.obj
error: can't find a port with a propeller chip
david-betzs-macbook-pro:p2load dbetz$ p2load foo.obj
Found propeller version 32 on /dev/cu.usbserial-A800f7XO
Loading 'foo.obj' at 0x00000e80
error: can't open 'foo.obj'
It will complain about the port though before complaining about a missing file if the port is not found since the port is opened before the file. Is that what is happening in your example?
I'm afraid I haven't made much progress on that. My current plan is to just use the existing -f p2load feature to write images to SPI flash and then write a simple program that will load SDRAM from flash and start your graphic programs. I'm not sure about adding SDRAM support directly to p2load since there is no standard way of interfacing to SDRAM. Once the actual chips come out different board designers will probably use different interfaces. I guess I could add a scheme for loading board-specific SDRAM drivers but I haven't thought about that enough to have a design in mind.
I think energy would be better spent writing an SD card interface for the P2, then you can write some files to the card and load them at runtime into SDRAM.
I think energy would be better spent writing an SD card interface for the P2, then you can write some files to the card and load them at runtime into SDRAM.
Comments
Sounds like we need another sticky.
I've never noticed. Will go look since you mentioned it though.
The problem with regular threads is they fall off the top over time and even google search is useless without terms.
I am trying to maintaint the first post in the sticky to anything new and relevant. If you need something updated there, preference is to detail it in a post to that thread, and I will update a summary on the first post. I will also link to a thread if relevant. If I do miss something, pm me.
I started a thread for P2 Drivers & Tools where you can add these references. I need to update the sticky with a link to this thread once it gains traction.
Thanks for that.
I noticed the first time your code failed to recognise the board. I have this occasionally on PST and other software on P1. PropTool always seems to find the board though. There must be something subtle in the timing. This is only the first time after the board is plugged in to the USB, so it is definately not a problem. I just re-ran p2load and it found the board.
By the way, the code I'm using to detect the P2 is a translation of Chip's Pascal code so I would think it would work as well as PNut. Of course, maybe I made an error in the translation.
I cannot say if pnut has always recognised the DE0 or not - just cannot recall. I do know that sometimes PST does not recognise the port first up, and I load PropTool and F7 to identify the port. PropTool always seems to work unless the USB breaks in windoze and that often requires a windoze reboot - not often, but it happens. Don't worry about it - I will keep an eye on it and see if there is any specifics in this, or just an occasional glitch.
The workflow is intended as thus:
ROM loads boot loader
ROM authenticates boot loader
boot loader runs
boot loader reads SPI flash contents into main memory
boot loader uses AES-128 in CBC mode to decrypt memory contents
boot loader chain loads to program in memory
There is little value in authenticating un-encrypted code, thus the SHA-256 engine shuts down. The data is right there in ROM, so you can launch it again if you want.
For all cases where authentication and encryption are unneeded, you simply leave the key all zeros, but as soon as you need to authenticate, you should also be encrypting the code too.
As for CBC vs other vector protocols, don't fret, CBC is used in A LOT of hardware/network security protocols, and there are no demonstrable exploits against it.
[ -r n, ] run program in COG n [ -r n,addr[:param] ] run program in COG n from addr with parameter paramThe first just sets the COG in which to run the main program. The second also allows you to specify the address of the COG image and the parameter to pass to coginit.I've also added some options to allow you to write data to flash:
[ -f file,faddr ] write contents of file to flash at faddr [ -f faddr,haddr,count ] write count bytes of hub data at haddr to flash at faddrThe first writes the contents of a file to flash at the specified address. The second writes data from hub memory to flash.Finally, I've added a way to write a bootable image to the flash. This makes it possible to have a program boot on reset without having to download it each time.
I now have Baggers' Fire demo running out of flash on my DE2-115 board! :-)
In addition to being attached to the top message of this thread this version is also checked into Google Code in the p2test branch.
NICE - Thanks
Have You PASM code to that You can post.
Thanks