Image 0 did not work. We now get rid of bootloader_backup_irq_table and
do this manually: We may not write to address 0 while an image is
running. So for image 0 we write the lower 8 pages to the backup
address. For all other images (ony image 1 currently) we write to
*both*, the original address *and* the backup address. This is done
because some addresses in the lower 8 pages *are* used at the original
address and the bootloader doesn't (want to) know which addresses are
which.
There are more safeguards now: We refuse to write to the active or
boot_next image (if boot_next is not boot_default). We mark the uploaded
partition as not ok.
Needs latest bootloader with commit ID a5771ae033b57.
Also get rid of genbackupisr hack: We can achieve the same thing with
avr-objcopy which doesn't need additional software.
We use the new bootloader setting for irq-save area of 0x800.
Compatible with old bootloader. Adds an additional section with a copy
of the interrupt vector table to the end of the image. This is needed by
the new bootloader and should be ok for the old bootloader.
Note that for this to work, everybody needs python installed with
the IntelHex python package. On Linux this can be achieved with
pip install IntelHex
Introduce new testing-app example.
Add a new coap error code for blockwise transfer.
Add include-file for bootloader callbacks (jumptable).
Note that only the bootloader for osd-merkur-256 will support
OTA-update, the -128 simply has not enough flash memory, so only
in the -256 we have the bootloader functions in the jump-table
of the bootloader and in the bootloader-if.h include-file.
The cc65 tool chain comes with V.24 drivers so it seems reasonable to use the existing Contiki SLIP driver to implement network access via SLIP as alternative to Ethernet.
Some notes:
- The Ethernet configuration was simplified in order to allow share it with SLIP.
- The Contiki SLIP driver presumes an interrupt driven serial receiver to write into the SLIP buffer. However the cc65 V.24 drivers aren't up to that. Therefore the main loops were extended to pull received data from the V.24 buffers and push it into the SLIP buffer.
- As far as I understand the serial sender is supposed to block until the data is sent. Therefore a loop calls the non-blocking V.24 driver until the data is sent.
On all platforms there's only one V.24 driver available. Therefore V.24 drivers are always loaded statically.
On the Apple][ the mouse driver is now loaded statically - independently from SLIP vs. Ethernet. After all there's only one mouse driver available. However there's a major benefit with SLIP: Here all drivers are loaded statically. Therefore the dynamic module loader isn't necessary at all. And without the loader the heap manager isn't necessary at all. This allows for a reduction in code size roughly compensating for the size of the SLIP buffer.
