Hi Freddie,
----- Ursprüngliche Mail ----
> > How would you write a board file for a board with two LPC2103 in the
> > chain? A simple source [find target/lpc2103.cfg] source [find
> > target/lpc2103.cfg] wouldn't work because it would try to declare two
> > targets with the same name (lpc2103.cpu).
> >
> > Previously it was possible to write: set CHIPNAME chip1 source [find
> > target/lpc2103.cfg] set CHIPNAME chip2 source [find
> > target/lpc2103.cfg] It gave you two targets chip1.cpu and chip2.cpu.
>
> You should not source lpc2103.cfg twice, but lpc2xxx_internals.tcl twice
> - with all necessary defines. A little more text unfortunately.
>
Yes, this is how it could be done. However, for the first instance you would
use the existing lpc2103.cfg, while for the second instance you had to copy the
content of that file into your board config. It's possible, but I don't think
it would be really straightforward.
If I understand your latest proposal correctly, CHIPNAME is just for info (for
naming the target). It's no longer being used in lpc2xxx_internals.tcl to
determine the defaults for a specific chip. This is now done in (for instance)
lpc2103.cfg. Why not just remove the CHIPNAME from the specific files, and just
use an overridable default ("lpc2000") in lpc2xxx_internals.tcl? This would
solve the multiple instantiation problem.
The target would be named lpc2000.cpu by default.
> Do you suggest renaming CRYSTAL_FREQ to (for example) CCLK_FREQ or some
> other changes?
>
No, it's fine as it is. Just has to be explained in the manual.
> > The reset init script must be available to the user, because he needs
> > it to add the PLL initialization. Where would I enable the PLL when a
> > default reset init script is already defined in the target script?
>
> From what I have noticed all LPC2xxx have exactly the same PLL configuration
> scheme, so that's more like target related in my opinion. The PLL setup code
> will work (when written right) on all LPC2xxx chips. The only concen is the
> difference between the chips with / without internal RC.
>
PLL blocks in LPC23xx and LPC21xx are different.
I admit that I don't have a good idea yet how this can be done properly.
> > The working area should start at 0x40000200. This makes sure that
> > there is no conflict with possible temporary storage of IAP code (has
> > been a problem in the past, although the 0x40000000--0x400001FF area
> > should have been used by ISP code only). A strict requirement is to
> > not touch the upper 32 bytes of the internal SRAM. This RAM area is
> > definitely used by the IAP routines internally!
>
> Sounds reasonable, but in my experience I haven't noticed any problems with
> using exactly whole RAM.
>
Currently the upper 32 bytes will not be used by the flash driver, but just by
chance. A future version of the driver might want to use that part of the
working area, and then we would be in trouble.
So I suggest to limit the working area to 0x40000200--(SRAM end - 32).
> > There are devices with external memory bus. A user might want to use
> > an external RAM for the working area instead of the internal SRAM.
> > Therefore I think the working area declaration is board specific and
> > doesn't belong to the target declaration.
>
> The start of working area can be made "overridable" with default being
> 0x40000000.
>
I had a quick look at the sources, and it looks like that you can have multiple
working area declarations. Only the last one will be used, so it's fine to have
a default working area.
If a user wants to utiize the external RAM of an LPC2468, he can just declare a
new working area.
> > What do you think about modifying the LPC2000 flash driver to adapt
> > itself to the various devices? It can read the part id and
> > auto-configure itself. You could keep the FLASH_SIZE and RAM_SIZE
> > variables to override any automatic detection. I feel it would make
> > life a lot easier!
>
> I've noticed that ideas of auto-whatever are not liked here <: For me that's
> cool, but beyond my knowledge.
>
I saw that, too :-)
I would volunteer to make the necessary changes to the lpc2000 driver. This is
my idea:
- Autodetect the device, and configure flash size and sector layout (variant)
automatically.
- Only use the autodetected values if the user has passed "0" in the
corresponding field of the flash bank declaration.
- Issue a warning if overridden values do not match autodetected values.
- Should there be new devices not yet supported by the driver, you may specify
everything manually.
- Doesn't break existing config files.
- Register the driver as "lpc2000" and "lpc1700". Allows to use real family
names, although (up to now) everything can be handled with one driver. In the
future, there could be a specific driver for each family without breaking
config files that we write now. Also allows to add new command handlers that
are specific for LPC1700.
Consequence: You do not have to set the FLASH_SIZE anywhere.
There is now only one reason left to have chip specific files: Set the RAM size
for an optimized working area.
As this is now the last reason to have a config file for each and every
LPC2000/LPC1700/... variant, I suggest we come up with an idea how we can get
rid of that.
I sharp contrast to others on this list, I think that
one-derivative-one-file-even-if-there-are-hundreds-of-them concept is a mess :-)
> With every modification that is suggested the script is becoming more and
> more
> complex. At the beginning (in my original idea) all that was required was the
> chip name. Then the part config files need all the details. Now there is a
> need
> for another level of abstraction with wrapper script to configure the clock.
> You
> propose individual reset-init scripts and individual work area placement...
>
> To be honest, I'm loosing the faith in this whole idea, because the complex
> is
> becoming more complex, not simple...
>
Don't lose faith, we will eventually make it :-)
Please continue to push this!
Regards,
Rolf
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
