[U-Boot] Toradex board with Colibri PXA270
Hello u-booters,
I'm currently working with a Toradex board featuring a Colibri PXA270 module, and I noticed this attempt to get a Colibri PXA270 patch applied
http://lists.denx.de/pipermail/u-boot/2009-April/050634.html
... which seems it didn't get anywhere further than so.
The conclusion, or should I say request, from there was to make more parts re-used within the source tree to reduce code duplication and I can only agree with that.
Seeing that this is a PXA(270) equipped board, wouldn't it make sense to do some of the low level init etc stuff in the cpu-specific area (cpu/pxa/) ? The entire gpio handling (and similar) is after all common for all PXA270 isn't it?
So, is there anyone with more specific thoughts or opinions on this? What can I do to push this forward to the next level?
On Tue, Apr 28, 2009 at 11:37:14AM +0200, Daniel Stenberg wrote:
I'm currently working with a Toradex board featuring a Colibri PXA270 module, and I noticed this attempt to get a Colibri PXA270 patch applied
http://lists.denx.de/pipermail/u-boot/2009-April/050634.html
... which seems it didn't get anywhere further than so.
The conclusion, or should I say request, from there was to make more parts re-used within the source tree to reduce code duplication and I can only agree with that.
Seeing that this is a PXA(270) equipped board, wouldn't it make sense to do some of the low level init etc stuff in the cpu-specific area (cpu/pxa/) ? The entire gpio handling (and similar) is after all common for all PXA270 isn't it?
So, is there anyone with more specific thoughts or opinions on this? What can I do to push this forward to the next level?
In case you do that, please call the board 'colibri-pxa270' in folder and config file names, not just 'colibri' like in the version you referred to above. There are versions of that modules with pxa3[012]0 CPUs which are entirely different and need extra care.
I submitted a patch to support that module 1,5 years ago - if you miss some pieces, you might have a look here:
http://lists.denx.de/pipermail/u-boot/2007-November/026890.html
Bringing this in shape is a good idea, though.
Daniel
On Tue, 28 Apr 2009, Daniel Mack wrote:
In case you do that, please call the board 'colibri-pxa270' in folder and config file names, not just 'colibri' like in the version you referred to above. There are versions of that modules with pxa3[012]0 CPUs which are entirely different and need extra care.
Good point and a fair suggestion!
I submitted a patch to support that module 1,5 years ago - if you miss some pieces, you might have a look here:
http://lists.denx.de/pipermail/u-boot/2007-November/026890.html
Thanks, that's actually what I've used as building bricks to get this all running on u-boot 1.3.4 locally, but I thought I'd put things together and help pushing all this into current mainline now.
Jean-Christophe, as PXA custodian, do you have any further thoughts on how to combine common code in a clever way to reduce duplcations?
On Tue, 28 Apr 2009, Daniel Stenberg wrote:
Jean-Christophe, as PXA custodian, do you have any further thoughts on how to combine common code in a clever way to reduce duplcations?
Since there was no feedback on this, I investigated a little further and I noticed that several existing ARM cores already do it this way (arm926ejs, arm926ejs, arm920t, etc) so I think there's then a nice prejudice to continue on this path.
There seem to be 13 PXA-based configs in include/configs:
include/configs/cerf250.h include/configs/cradle.h include/configs/csb226.h include/configs/innokom.h include/configs/logodl.h include/configs/lubbock.h include/configs/pleb2.h include/configs/pxa255_idp.h include/configs/trizepsiv.h include/configs/wepep250.h include/configs/xaeniax.h include/configs/xm250.h include/configs/xsengine.h
... and all these boards have their own private lowlevel_init.S files and given a quick glance, this looks like lots of next to identical source codes.
But only one of these are PXA270 based, and I'm not fluent enough in the PXA world to tell how much that can be re-used between PXA models or similar.
On 11:49 Wed 29 Apr , Daniel Stenberg wrote:
On Tue, 28 Apr 2009, Daniel Stenberg wrote:
Jean-Christophe, as PXA custodian, do you have any further thoughts on how to combine common code in a clever way to reduce duplcations?
Since there was no feedback on this, I investigated a little further and I noticed that several existing ARM cores already do it this way (arm926ejs, arm926ejs, arm920t, etc) so I think there's then a nice prejudice to continue on this path.
yes that's the correct idea
I've some old patch that start to do it if you are interrested to continue on it
There seem to be 13 PXA-based configs in include/configs:
include/configs/cerf250.h include/configs/cradle.h include/configs/csb226.h include/configs/innokom.h include/configs/logodl.h include/configs/lubbock.h include/configs/pleb2.h include/configs/pxa255_idp.h include/configs/trizepsiv.h include/configs/wepep250.h include/configs/xaeniax.h include/configs/xm250.h include/configs/xsengine.h
... and all these boards have their own private lowlevel_init.S files and given a quick glance, this looks like lots of next to identical source codes.
But only one of these are PXA270 based, and I'm not fluent enough in the PXA world to tell how much that can be re-used between PXA models or similar.
for the pxa2xx I can help you, for the pxa3xx I've no board
Best Regards, J.
On Wed, 29 Apr 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
Since there was no feedback on this, I investigated a little further and I noticed that several existing ARM cores already do it this way (arm926ejs, arm926ejs, arm920t, etc) so I think there's then a nice prejudice to continue on this path.
yes that's the correct idea
I've some old patch that start to do it if you are interrested to continue on it
If you post it (or point me to where I can find it) I can at least get a grip of what you're suggesting and then see what I can do.
My actual plan is to help get the colibri-pxa270 stuff merged in, but it seems we should fix some duplication first to make way for that.
But only one of these are PXA270 based, and I'm not fluent enough in the PXA world to tell how much that can be re-used between PXA models or similar.
for the pxa2xx I can help you, for the pxa3xx I've no board
I'll very soon not have any PXA board at all... :-) I was mostly (at this point) thinking about the knowledge about how they differ and similar. I mean, does it make sense to try to make a single lowlevel_init.S for all PXAXXX models or one for each PXA2xx/PXA3xx or do we need PXA25x/PXA27X/PXA3xx etc...
But I guess your initial patch might reveal that to me?
participants (3)
-
Daniel Mack -
Daniel Stenberg -
Jean-Christophe PLAGNIOL-VILLARD