Re: [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC

Dear Simon Glass,
In message 1363020460-14307-1-git-send-email-sjg@chromium.org you wrote:
This series creates a generic board init implementation which contains the essential functions of the major arch/xxx/lib/board.c files. It is split into two parts: board_f.c for pre-relocation and board_r.c for post-relocation.
...
ARM is a relatively large board.c file and one which I can test, therefore I think it is a good target for this series. On the other hand, x86 is relatively small and simple, but different enough that it introduces a few issues to be solved. So I have chosen both ARM and x86 for this series. After a suggestion from Wolfgang I have added PPC also. This is the largest and most feature-full board, so hopefully we have all bases covered in this series. Other archs are mostly a subset of these.
I did some testing on Power Architecture systems - to be precise:
CPU Board -------------------------- MPC860T TQM860L MPC5200 TQM5200S PPC405EX Kilauea PPC440EP Yosemite PPC440EX Sequoia PPC440SPe Katmai PPC460EX Canyonlands
On all boards I verified at least environment access (printenv, saveenv) and network operation (TFTP download); where available also PCI. Everything appears to work fine, no problems noted.
A well done job, thanks a lot!
For the whole series:
Tested-by: Wolfgang Denk wd@denx.de Acked-by: Wolfgang Denk wd@denx.de
Best regards,
Wolfgang Denk

On Wed, Mar 13, 2013 at 09:46:26AM +0100, Wolfgang Denk wrote:
Dear Simon Glass,
In message 1363020460-14307-1-git-send-email-sjg@chromium.org you wrote:
This series creates a generic board init implementation which contains the essential functions of the major arch/xxx/lib/board.c files. It is split into two parts: board_f.c for pre-relocation and board_r.c for post-relocation.
...
ARM is a relatively large board.c file and one which I can test, therefore I think it is a good target for this series. On the other hand, x86 is relatively small and simple, but different enough that it introduces a few issues to be solved. So I have chosen both ARM and x86 for this series. After a suggestion from Wolfgang I have added PPC also. This is the largest and most feature-full board, so hopefully we have all bases covered in this series. Other archs are mostly a subset of these.
I did some testing on Power Architecture systems - to be precise:
CPU Board
MPC860T TQM860L MPC5200 TQM5200S PPC405EX Kilauea PPC440EP Yosemite PPC440EX Sequoia PPC440SPe Katmai PPC460EX Canyonlands
On all boards I verified at least environment access (printenv, saveenv) and network operation (TFTP download); where available also PCI. Everything appears to work fine, no problems noted.
A well done job, thanks a lot!
For the whole series:
Tested-by: Wolfgang Denk wd@denx.de Acked-by: Wolfgang Denk wd@denx.de
OK, I've taken http://patchwork.ozlabs.org/bundle/sjg/us-board/ but with http://patchwork.ozlabs.org/patch/228080/ for 2/31 and applied this to u-boot/master now, thanks again!

Hi Wolfgang,
On Wed, Mar 13, 2013 at 1:46 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message 1363020460-14307-1-git-send-email-sjg@chromium.org you wrote:
This series creates a generic board init implementation which contains the essential functions of the major arch/xxx/lib/board.c files. It is split into two parts: board_f.c for pre-relocation and board_r.c for post-relocation.
...
ARM is a relatively large board.c file and one which I can test,
therefore
I think it is a good target for this series. On the other hand, x86 is relatively small and simple, but different enough that it introduces a few issues to be solved. So I have chosen both ARM and x86 for this
series.
After a suggestion from Wolfgang I have added PPC also. This is the largest and most feature-full board, so hopefully we have all bases covered in this series. Other archs are mostly a subset of these.
I did some testing on Power Architecture systems - to be precise:
CPU Board
MPC860T TQM860L MPC5200 TQM5200S PPC405EX Kilauea PPC440EP Yosemite PPC440EX Sequoia PPC440SPe Katmai PPC460EX Canyonlands
On all boards I verified at least environment access (printenv, saveenv) and network operation (TFTP download); where available also PCI. Everything appears to work fine, no problems noted.
A well done job, thanks a lot!
Thanks for your comments which are much appreciated. There is still work to do, in cleaning up the implementation to reduce the differences between arch code (e.g. all the #ifdefs in board_f/r.c). But this is a great first step and I am pleased to get this in.
For the whole series:
Tested-by: Wolfgang Denk wd@denx.de Acked-by: Wolfgang Denk wd@denx.de
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Certain old men prefer to rise at dawn, taking a cold bath and a long walk with an empty stomach and otherwise mortifying the flesh. They then point with pride to these practices as the cause of their sturdy health and ripe years; the truth being that they are hearty and old, not because of their habits, but in spite of them. The reason we find only robust persons doing this thing is that it has killed all the others who have tried it. - Ambrose Bierce, "The Devil's Dictionary"
But I wonder if this is trying to tell me to stop these tricky refactors :-)
Regards, Simon
participants (3)
-
Simon Glass
-
Tom Rini
-
Wolfgang Denk