Re: AT91 serial driver

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

> Why is this the case?  We make every effort to keep the "core" sources
> in such a state that they are usable by everyone and the design is _supposed_
> to be such that extraordinary circumstances can be handled outside of the
> kernel - in other words, we try to not ever have it be the case that changes
> need to be made to the kernel proper which can't be used, or at least present
> if not enabled, by everyone.
>
> If you can explain why this doesn't work for you, we'd (at least me) would
> like to understand your situation.

Numerous issues. On top of my head, an incomplete list no particular
order:

- I had to write my own bootloader. 
- The AT91 port does not have configurability of the remap/chip
select/wait state stuff, other than modifying the machinecode directly.
- To support C++ multithreaded exception handling, I had to modify the
eCos scheduler.
- It was deemed unacceptable that the remap operation happened in the
bootloader and not the firmware/application. Hence I needed to create a
scheme whereby the firmware was executed *before* the at91 hardware
remap, if the bootloader was not launched.
- My bootloader allows upload directly via serial ymodem to flash. THe
bootloader runs out of RAM, so I can leave interrupts running while
programming flash. The main application, however, runs out of flash and
hence I need a scheme to disable interrupts the flash is being
erased/written.
- The only thing I used from Redboot was the ymodem code, which is not a
seperate module such as the CRC calculations. 
- The AT91 hw reset code, only resets the CPU, not the external devices,
such as the flash. Application specific?
- AT91 flash hardware write protection support
- JFFS2 uses too much ram
- JFFS2 does not work with single sector mounts
- etc.

In some cases, I've posted patches that were accepted. In other the
patches where rejected for reasons I concur with, in other cases there
just hasn't been created a strong enough consensus yet.

eCos was the best possible starting point for creating a shipping
product with the minimum effort, in my case.

Ãyvind