[Bug 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usageand NXP flash checksum

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001395

--- Comment #5 from Bernard Fouchà <bernard.fouche@kuantic.com> 2011-12-06 11:21:01 GMT ---
(In reply to comment #4)
>[snip]
> Seem there has been some development at NXP in meantime that is new to me (LPC
> is not in my focus recently). However I feel responsible for the mess and I
> would prepare patches for this and for other bugs. The question for this one:
> Do we give up these 32 bytes for good or make it configurable?
> 
> And since there are many things to fix (revisiting LPC17xx I found some bugs
> too) :( what would be preferable: to prepare a separate fix for every bug or
> one big patch?

I would vote for separate bug entries, even if they all point to a single patch
(to ease bug search/tracking with bugzilla)

I've to do the FSF paperwork for a colleague and I, and we'll contribute:

- hardware watchdog
- spi driver
- CAN driver (derived of course from LPC2XXX)
- spansion S25FLxxx
- revisited lpx17xxx_misc.c/cdl (making USB clock generation as an
option,CLKOUT as an option, complete disconnection of PLL, SPP clocks as
options,should be extended to everything that clocks :-))

Expect these for Q1-2012. We are basing our new product line on the LPC, so we
should keep working on the LPC for the next years.

I'll also open a bug/discussion about power management since the LPC allow fine
tuning of power, including generic peripherals like the 16x5x driver and some
solution must be found to add power management everywhere.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.