Mailbox details?
pedward
Posts: 1,642
Has a consensus on the Mailbox location, size, and format been reached?
I'm working on a few ideas at once and want to get this sorted first.
I'm working on the boot loader, with AES-128 decryption, and I'm working on Ethernet. For the latter I want the driver to use a standard convention for mailbox.
I'm working on a few ideas at once and want to get this sorted first.
I'm working on the boot loader, with AES-128 decryption, and I'm working on Ethernet. For the latter I want the driver to use a standard convention for mailbox.
Comments
Refresh
The beauty of disconnecting the bootloader from the ROM, but authenticating it, is that you can have a myriad of different bootloaders to fit your specific need. I'm just trying to fulfill the original vision and offer a standard bearer for launch.
I have kept out of the mailbox discussion while I work on a bootloader that could work with whatever other people agree on. Also, I guess there isn't necessarily a need for all P2 programs to follow the same conventions although it would make reusing drivers easier. I was hoping that RossH would participate in this discussion because of his experience with doing something similar in Catalina C but he seems to have disappeared.
Choices:
1) Use it until you find it doesn't fit your needs, then do something else.
2) Ignore it and move on.
I'm curious about your thoughts as to why it such a methodology necessary.
I understand it can have value, but I can live without it in most cases.
I'm not trying to start a brawl; I just want to read your opinion because I respect you.
I propose to do this by putting the start location at $1000, so I can use the lower 4K chunk to hold the bootloader and associated data. This will also facilitate reprogramming the flash without touching the bootloader, which also opens up everything from $20000 on to the program code, having only $1000-$1FFFF tied up with some hard and fast rule.
I'm simultaneously looking at an Ethernet driver and I want the code to use a mailbox structure to make life easier and make it language agnostic. If the mailbox format listed in the thread referenced has been agreed upon in some semi-official manner, I'm happy to use it.
The bootloader won't need more than one COG or any reserved space, other than the first flash chunk.
I seem to recall that the flash chips are 4K page size? One of the criteria for a field upgrade should be recoverability. Perhaps re-thinking the flash format a little bit in order to accommodate $E80-$FFF and have a recoverable flash section? Perhaps a double buffered image, so when you flash a new image in the field, if something goes wrong it won't switch from the primary to the secondary?
Sort of like double buffering, just toggle between image locations, or once the secondary has booted it should rewrite the primary?
I'll check the mailbox thread to make sure its up to date, I think I've been working to the latest posted version; if not I'll update it.
Glad to have you on-board with the mailboxes
If possible, can you post how I can integrate a PASM blob with propgcc? That will help get demos out faster
The limiting gcc to the first 32KB of HUB is not critical for SDRAM graphics drivers, it only matters for the 96KB hub frame buffers I've been using. For smaller hub buffers, I could declare the frame buffer as an integer array, and pass the address through cognew.