* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
[not found] <1363021453-6566-1-git-send-email-sjg@chromium.org>
@ 2013-03-11 17:50 ` Simon Glass
2013-03-13 3:52 ` Simon Glass
1 sibling, 0 replies; 9+ messages in thread
From: Simon Glass @ 2013-03-11 17:50 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass <sjg@chromium.org> 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.
>
> What is the motivation for this change?
>
> 1. There is a lot of repeated code in the board.c files. Any change to
> things like setting up the baud rate requires a change in 10 separate
> places.
>
> 2. Since there are 14 separate files, adding a new feature which requires
> initialisation is painful since it must be independently added in 14
> places.
>
> 3. As time goes by the architectures naturely diverge since there is
> limited
> pressure to compare features or even CONFIG options against simiilar things
> in other board.c files.
>
> 4. New architectures must implement all the features all over again, and
> sometimes in subtley different ways. This places an unfair burden on
> getting
> a new architecture fully functional and running with U-Boot.
>
> 5. While it is a bit of a tricky change, I believe it is worthwhile and
> achievable. There is no requirement that all code be common, only that
> the code that is common should be located in common/board.c rather than
> arch/xxx/lib/board.c.
>
> All the functions of board_init_f() and board_init_r() are broken into
> separate function calls so that they can easily be included or excluded
> for a particular architecture. It also makes it easier to adopt Graeme's
> initcall proposal assuming this comes about.
>
> http://lists.denx.de/pipermail/u-boot/2012-January/114499.html
>
> This series is not dependent on generic relocation. So relocation
> happens as one big chunk and is still completely arch-specific. See the
> relocation series for a proposed solution to this for ARM:
>
> http://lists.denx.de/pipermail/u-boot/2011-December/112928.html
>
> or x86's implementation which is in mainline. Unifying relocation is
> probably the next step after this series.
>
> Instead of moving over a whole architecture, this series takes the approach
> of simply enabling generic board support for an architecture. It is then up
> to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board
> config file. If this is not done, then the code will be generated as
> before. This allows both sets of code to co-exist until we are comfortable
> with the generic approach, and enough boards run.
>
> 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.
>
> A generic global_data structure is now in mainline, and this is required
> for this series.
>
> Similarly we need a generic bd_info structure, since generic code will
> be accessing it. I have done this with a simple generic file for now.
>
> There was dicussion on the list about passing gd_t around as a parameter
> to pre-relocation init functions. I think this makes sense, but it can
> be done as a separate change, and this series does not require it.
>
> While this series needs to stand on its own, the goal is the unification
> of the board init code. So I hope we can address issues with this in mind,
> rather than focusing too narrowly on particular ARM, x86 or PPC issues.
> I have added TODO markers in places where I think there are opportunities
> to relationalise the board init now it is all in one place, but these don't
> need to be addressed for the feature to work, and are best done as smaller
> patches than can be reviewed by individual arch maintainers, I think.
>
> I have run-tested ARM on Tegra Seaboard and x86/coreboot only. To try it
> out, define CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most
> likely on PPC at least it will hang, but if you are lucky it will print
> something first :-) I hope to test an SPL board (snow / exynos5250) when
> I can get that booting from mainline.
>
> I have run this though buildman with CONFIG_SYS_GENERIC_BOARD on for all
> ARM, PPC and x86 boards. The only failure is highbank (an ARM board), which
> seems to use SCSI but scsi_init() is not available.
>
> Code size increases by about 1KB on ARM and about 1.3KB on PPC with generic
> board enabled. This is mostly due to the move to using separate functions
> for each part of the init, which will make it easier to move to a pure
> initcall approach later if we want to.
>
> Since this series was first sent there have been additions to the board
> code for ARM and PPC. I have added in these additions. This is a manual
> process, and I expect that people will find problems (and send patches)
> as they try out their boards.
>
I have created a branch on x86 for this as follows, in case this helps. But
I believe Wolfgang is hoping to look at getting it running on PowerPC, so
it might be worth holding off for more news.
The following changes since commit fc959081d41aab2d6f4614c5fb3dd1b77ffcdcf4:
x86: Enable CONFIG_OF_CONTROL on coreboot (2013-03-04 15:57:52 -0800)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git us-board-v10
for you to fetch changes up to 0a2cdf0f505a018e5a781750ada081ac6e81a866:
Use 'unsigned int' for global_data's baudrate (2013-03-11 10:42:20 -0700)
----------------------------------------------------------------
Simon Glass (31):
Introduce generic u-boot.h file
Replace __bss_end__ with __bss_end
Introduce generic link section.h symbol files
arm: Use sections header to obtain link symbols
Change stub example to use asm-generic/sections.h
Introduce a basic initcall implementation
__HAVE_ARCH_GENERIC_BOARD controls availabilty of generic board
Declare watchdog functions in watchdog.h
Introduce generic pre-relocation board_f.c
Introduce generic post-relocation board_r.c
Add spl load feature
arm: Remove use of board_early_init_r/last_stage_init()
arm: Enable generic board support
Add CONFIG_SYS_SYM_OFFSETS to support offset symbols
Adjust board_f.c for ppc
Adjust board_r.c for ppc
ppc: Enable generic board support
x86: Adjust board_f.c for x86
x86: Adjust board_r.c for x86
x86: Use sections header to obtain link symbols
tegra: Enable generic board for Tegra
x86: Enable generic board support
x86: Enable generic board
exynos5: Enable generic board for Exynos5 device tree boards
blackfin: Fix up board_type global data
blackfin: Remove noreturn attribute from cpu_init_f()
avr32: Fix cast warning in board.c
serial: ns16550: Remove unwanted cast
sparc: Fix out-of-tree building
sparc: Fix build warnings in serial.c
Use 'unsigned int' for global_data's baudrate
README | 17 +
arch/arm/config.mk | 3 +
arch/arm/cpu/arm1136/start.S | 2 +-
arch/arm/cpu/arm1136/u-boot-spl.lds | 2 +-
arch/arm/cpu/arm1176/start.S | 2 +-
arch/arm/cpu/arm720t/start.S | 2 +-
arch/arm/cpu/arm920t/ep93xx/u-boot.lds | 2 +-
arch/arm/cpu/arm920t/start.S | 2 +-
arch/arm/cpu/arm925t/start.S | 2 +-
arch/arm/cpu/arm926ejs/davinci/spl.c | 2 +-
arch/arm/cpu/arm926ejs/mxs/start.S | 2 +-
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 2 +-
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds | 2 +-
arch/arm/cpu/arm926ejs/start.S | 4 +-
arch/arm/cpu/arm946es/start.S | 2 +-
arch/arm/cpu/arm_intcm/start.S | 2 +-
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds | 2 +-
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds | 2 +-
arch/arm/cpu/armv7/start.S | 2 +-
arch/arm/cpu/ixp/start.S | 2 +-
arch/arm/cpu/ixp/u-boot.lds | 2 +-
arch/arm/cpu/pxa/start.S | 2 +-
arch/arm/cpu/s3c44b0/start.S | 2 +-
arch/arm/cpu/sa1100/start.S | 2 +-
arch/arm/cpu/u-boot.lds | 4 +-
arch/arm/include/asm/sections.h | 27 +
arch/arm/include/asm/spl.h | 2 +-
arch/arm/include/asm/u-boot-arm.h | 4 -
arch/arm/include/asm/u-boot.h | 9 +
arch/arm/lib/Makefile | 3 +
arch/arm/lib/board.c | 1 +
arch/arm/lib/crt0.S | 4 +-
arch/arm/lib/spl.c | 2 +-
arch/avr32/cpu/start.S | 2 +-
arch/avr32/cpu/u-boot.lds | 2 +-
arch/avr32/include/asm/sections.h | 6 +-
arch/avr32/lib/board.c | 8 +-
arch/blackfin/cpu/cpu.c | 1 -
arch/blackfin/include/asm/global_data.h | 1 +
arch/blackfin/include/asm/sections.h | 27 +
arch/blackfin/lib/board.c | 2 +-
arch/m68k/include/asm/sections.h | 27 +
arch/m68k/lib/board.c | 5 +-
arch/microblaze/include/asm/sections.h | 27 +
arch/mips/include/asm/sections.h | 27 +
arch/mips/include/asm/u-boot-mips.h | 4 +-
arch/nds32/cpu/n1213/start.S | 2 +-
arch/nds32/cpu/n1213/u-boot.lds | 2 +-
arch/nds32/include/asm/sections.h | 27 +
arch/nds32/include/asm/u-boot-nds32.h | 8 +-
arch/nds32/lib/board.c | 2 +-
arch/nios2/cpu/start.S | 6 +-
arch/nios2/cpu/u-boot.lds | 2 +-
arch/nios2/include/asm/sections.h | 27 +
arch/openrisc/include/asm/sections.h | 27 +
arch/powerpc/config.mk | 3 +
arch/powerpc/cpu/74xx_7xx/start.S | 4 +-
arch/powerpc/cpu/74xx_7xx/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc512x/start.S | 4 +-
arch/powerpc/cpu/mpc512x/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc5xx/start.S | 4 +-
arch/powerpc/cpu/mpc5xx/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc5xxx/spl_boot.c | 2 +-
arch/powerpc/cpu/mpc5xxx/start.S | 4 +-
arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds | 2 +-
arch/powerpc/cpu/mpc5xxx/u-boot-spl.lds | 2 +-
arch/powerpc/cpu/mpc5xxx/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc8220/start.S | 4 +-
arch/powerpc/cpu/mpc8220/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc824x/start.S | 4 +-
arch/powerpc/cpu/mpc824x/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc8260/start.S | 4 +-
arch/powerpc/cpu/mpc8260/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc83xx/start.S | 4 +-
arch/powerpc/cpu/mpc83xx/u-boot-spl.lds | 4 +-
arch/powerpc/cpu/mpc83xx/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc85xx/start.S | 4 +-
arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 2 +-
arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds | 2 +-
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 2 +-
arch/powerpc/cpu/mpc85xx/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc86xx/start.S | 4 +-
arch/powerpc/cpu/mpc86xx/u-boot.lds | 2 +-
arch/powerpc/cpu/mpc8xx/start.S | 4 +-
arch/powerpc/cpu/ppc4xx/start.S | 4 +-
arch/powerpc/cpu/ppc4xx/u-boot.lds | 2 +-
arch/powerpc/include/asm/sections.h | 27 +
arch/powerpc/include/asm/spl.h | 2 +-
arch/powerpc/include/asm/u-boot.h | 7 +
arch/powerpc/lib/Makefile | 2 +
arch/powerpc/lib/board.c | 18 +-
arch/sandbox/include/asm/sections.h | 2 +
arch/sh/cpu/sh2/u-boot.lds | 2 +-
arch/sh/cpu/sh3/u-boot.lds | 2 +-
arch/sh/cpu/sh4/u-boot.lds | 2 +-
arch/sh/include/asm/sections.h | 27 +
arch/sh/lib/board.c | 1 +
arch/sparc/cpu/leon2/Makefile | 7 -
arch/sparc/cpu/leon2/serial.c | 10 -
arch/sparc/cpu/leon3/Makefile | 7 -
arch/sparc/cpu/leon3/serial.c | 10 -
arch/sparc/include/asm/sections.h | 27 +
arch/x86/config.mk | 3 +
arch/x86/cpu/coreboot/sdram.c | 1 +
arch/x86/cpu/u-boot.lds | 4 +-
arch/x86/include/asm/config.h | 1 +
arch/x86/include/asm/sections.h | 27 +
arch/x86/include/asm/u-boot-x86.h | 9 -
arch/x86/include/asm/u-boot.h | 11 +
arch/x86/lib/Makefile | 3 +
arch/x86/lib/board.c | 3 +-
arch/x86/lib/init_helpers.c | 3 +-
arch/x86/lib/relocate.c | 9 +-
board/BuS/eb_cpu5282/u-boot.lds | 2 +-
board/LEOX/elpt860/u-boot.lds | 2 +-
board/RPXClassic/u-boot.lds | 2 +-
board/RPXlite/u-boot.lds | 2 +-
board/RPXlite_dw/u-boot.lds | 2 +-
board/RRvision/u-boot.lds | 2 +-
board/actux1/u-boot.lds | 2 +-
board/actux2/u-boot.lds | 2 +-
board/actux3/u-boot.lds | 2 +-
board/adder/u-boot.lds | 2 +-
board/ait/cam_enc_4xx/u-boot-spl.lds | 2 +-
board/altera/nios2-generic/u-boot.lds | 2 +-
board/amcc/acadia/u-boot-nand.lds | 2 +-
board/amcc/bamboo/u-boot-nand.lds | 2 +-
board/amcc/canyonlands/u-boot-nand.lds | 2 +-
board/amcc/kilauea/u-boot-nand.lds | 2 +-
board/amcc/sequoia/u-boot-nand.lds | 2 +-
board/amcc/sequoia/u-boot-ram.lds | 2 +-
board/astro/mcf5373l/u-boot.lds | 2 +-
board/cm4008/flash.c | 1 +
board/cm41xx/flash.c | 1 +
board/cobra5272/u-boot.lds | 2 +-
board/cogent/u-boot.lds | 2 +-
board/dave/PPChameleonEVB/u-boot.lds | 2 +-
board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 2 +-
board/davinci/da8xxevm/u-boot-spl-hawk.lds | 2 +-
board/dvlhost/u-boot.lds | 2 +-
board/eltec/mhpc/u-boot.lds | 2 +-
board/emk/top860/u-boot.lds | 2 +-
board/ep88x/u-boot.lds | 2 +-
board/esd/dasa_sim/u-boot.lds | 2 +-
board/esd/pmc440/u-boot-nand.lds | 2 +-
board/esd/tasreg/u-boot.lds | 2 +-
board/esteem192e/u-boot.lds | 2 +-
board/evb64260/u-boot.lds | 2 +-
board/fads/u-boot.lds | 2 +-
board/flagadm/u-boot.lds | 2 +-
board/freescale/m5208evbe/u-boot.lds | 2 +-
board/freescale/m52277evb/u-boot.lds | 2 +-
board/freescale/m5235evb/u-boot.lds | 2 +-
board/freescale/m5249evb/u-boot.lds | 2 +-
board/freescale/m5253demo/u-boot.lds | 2 +-
board/freescale/m5253evbe/u-boot.lds | 2 +-
board/freescale/m5271evb/u-boot.lds | 2 +-
board/freescale/m5272c3/u-boot.lds | 2 +-
board/freescale/m5275evb/u-boot.lds | 2 +-
board/freescale/m5282evb/u-boot.lds | 2 +-
board/freescale/m53017evb/u-boot.lds | 2 +-
board/freescale/m5329evb/u-boot.lds | 2 +-
board/freescale/m5373evb/u-boot.lds | 2 +-
board/freescale/m54418twr/u-boot.lds | 2 +-
board/freescale/m54451evb/u-boot.lds | 2 +-
board/freescale/m54455evb/u-boot.lds | 2 +-
board/freescale/m547xevb/u-boot.lds | 2 +-
board/freescale/m548xevb/u-boot.lds | 2 +-
board/freescale/mx31ads/u-boot.lds | 2 +-
board/gaisler/gr_cpci_ax2000/u-boot.lds | 2 +-
board/gaisler/gr_ep2s60/u-boot.lds | 2 +-
board/gaisler/gr_xc3s_1500/u-boot.lds | 2 +-
board/gaisler/grsim/u-boot.lds | 2 +-
board/gaisler/grsim_leon2/u-boot.lds | 2 +-
board/gen860t/u-boot-flashenv.lds | 2 +-
board/gen860t/u-boot.lds | 2 +-
board/genietv/u-boot.lds | 2 +-
board/hermes/u-boot.lds | 2 +-
board/hymod/u-boot.lds | 2 +-
board/icu862/u-boot.lds | 2 +-
board/idmr/u-boot.lds | 2 +-
board/ip860/u-boot.lds | 2 +-
board/ivm/u-boot.lds | 2 +-
board/korat/u-boot-F7FC.lds | 2 +-
board/kup/kup4k/u-boot.lds | 2 +-
board/kup/kup4x/u-boot.lds | 2 +-
board/lwmon/u-boot.lds | 2 +-
board/manroland/uc100/u-boot.lds | 2 +-
board/matrix_vision/mvsmr/u-boot.lds | 2 +-
board/mbx8xx/u-boot.lds | 2 +-
board/mousse/u-boot.lds | 2 +-
board/mvblue/u-boot.lds | 2 +-
board/netphone/u-boot.lds | 2 +-
board/netta/u-boot.lds | 2 +-
board/netta2/u-boot.lds | 2 +-
board/netvia/u-boot.lds | 2 +-
board/nx823/u-boot.lds | 2 +-
board/quantum/u-boot.lds | 2 +-
board/r360mpi/u-boot.lds | 2 +-
board/rbc823/u-boot.lds | 2 +-
board/renesas/sh7752evb/u-boot.lds | 2 +-
board/renesas/sh7757lcr/u-boot.lds | 2 +-
board/rsdproto/u-boot.lds | 2 +-
board/samsung/smdk5250/smdk5250-uboot-spl.lds | 2 +-
board/samsung/smdk6400/u-boot-nand.lds | 2 +-
board/sandpoint/u-boot.lds | 2 +-
board/sixnet/u-boot.lds | 2 +-
board/snmc/qs850/u-boot.lds | 2 +-
board/snmc/qs860t/u-boot.lds | 2 +-
board/spc1920/u-boot.lds | 2 +-
board/spd8xx/u-boot.lds | 2 +-
board/stx/stxxtc/u-boot.lds | 2 +-
board/svm_sc8xx/u-boot.lds | 2 +-
board/tqc/tqm8xx/u-boot.lds | 2 +-
board/v37/u-boot.lds | 2 +-
board/vpac270/u-boot-spl.lds | 2 +-
board/woodburn/woodburn.c | 2 +-
common/Makefile | 4 +
common/board_f.c | 1016
+++++++++++++++++++++++++++++
common/board_r.c | 919
++++++++++++++++++++++++++
config.mk | 8 +
drivers/serial/ns16550.c | 2 +-
examples/standalone/stubs.c | 7 +-
include/asm-generic/global_data.h | 4 +-
include/asm-generic/sections.h | 117 ++++
include/asm-generic/u-boot.h | 162 +++++
include/common.h | 2 +
include/configs/exynos5250-dt.h | 1 +
include/configs/km/keymile-common.h | 4 -
include/configs/km/km-powerpc.h | 4 +
include/configs/tegra-common.h | 2 +
include/ide.h | 7 +
include/initcall.h | 25 +
include/watchdog.h | 18 +
lib/Makefile | 1 +
lib/initcall.c | 39 ++
nand_spl/board/amcc/acadia/u-boot.lds | 2 +-
nand_spl/board/amcc/bamboo/u-boot.lds | 2 +-
nand_spl/board/amcc/canyonlands/u-boot.lds | 2 +-
nand_spl/board/amcc/kilauea/u-boot.lds | 2 +-
nand_spl/board/amcc/sequoia/u-boot.lds | 2 +-
nand_spl/board/freescale/mpc8315erdb/u-boot.lds | 4 +-
nand_spl/board/freescale/mx31pdk/u-boot.lds | 2 +-
nand_spl/board/karo/tx25/u-boot.lds | 2 +-
nand_spl/board/samsung/smdk6400/u-boot.lds | 2 +-
nand_spl/board/sheldon/simpc8313/u-boot.lds | 4 +-
246 files changed, 2958 insertions(+), 294 deletions(-)
create mode 100644 arch/arm/include/asm/sections.h
create mode 100644 arch/blackfin/include/asm/sections.h
create mode 100644 arch/m68k/include/asm/sections.h
create mode 100644 arch/microblaze/include/asm/sections.h
create mode 100644 arch/mips/include/asm/sections.h
create mode 100644 arch/nds32/include/asm/sections.h
create mode 100644 arch/nios2/include/asm/sections.h
create mode 100644 arch/openrisc/include/asm/sections.h
create mode 100644 arch/powerpc/include/asm/sections.h
create mode 100644 arch/sh/include/asm/sections.h
create mode 100644 arch/sparc/include/asm/sections.h
create mode 100644 arch/x86/include/asm/sections.h
create mode 100644 common/board_f.c
create mode 100644 common/board_r.c
create mode 100644 include/asm-generic/sections.h
create mode 100644 include/asm-generic/u-boot.h
create mode 100644 include/initcall.h
create mode 100644 lib/initcall.c
Regards,
Simon
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
[not found] <1363021453-6566-1-git-send-email-sjg@chromium.org>
2013-03-11 17:50 ` [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC Simon Glass
@ 2013-03-13 3:52 ` Simon Glass
2013-03-13 13:16 ` Andreas Bießmann
1 sibling, 1 reply; 9+ messages in thread
From: Simon Glass @ 2013-03-13 3:52 UTC (permalink / raw)
To: u-boot
Hi,
On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass <sjg@chromium.org> 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.
I forgot to mention that if anyone wants to try this out on their
board, the tree is at
http://git.denx.de/u-boot-x86.git
branch 'us-board-v11'
Regards,
Simon
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
2013-03-11 16:49 ` [U-Boot] [PATCH v9 09/31] Introduce generic pre-relocation board_f.c Simon Glass
@ 2013-03-13 8:46 ` Wolfgang Denk
2013-03-15 22:23 ` Tom Rini
2013-03-30 21:34 ` Simon Glass
0 siblings, 2 replies; 9+ messages in thread
From: Wolfgang Denk @ 2013-03-13 8:46 UTC (permalink / raw)
To: u-boot
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
--
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 at 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"
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
2013-03-13 3:52 ` Simon Glass
@ 2013-03-13 13:16 ` Andreas Bießmann
2013-03-13 16:25 ` Tom Rini
0 siblings, 1 reply; 9+ messages in thread
From: Andreas Bießmann @ 2013-03-13 13:16 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 03/13/2013 04:52 AM, Simon Glass wrote:
> Hi,
>
> On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass <sjg@chromium.org> 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.
I tested the whole series on avr32. The minor changes there do not break
runtime behaviour, therefore
Tested-by: Andreas Bie?mann <andreas.biessmann@googlemail.com>
Will this series be applied for upcomming release? I'm asking cause of
http://patchwork.ozlabs.org/patch/225225/
vs
http://patchwork.ozlabs.org/patch/220413/
Best regards
Andreas Bie?mann
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
2013-03-13 13:16 ` Andreas Bießmann
@ 2013-03-13 16:25 ` Tom Rini
2013-03-13 22:20 ` Simon Glass
0 siblings, 1 reply; 9+ messages in thread
From: Tom Rini @ 2013-03-13 16:25 UTC (permalink / raw)
To: u-boot
On Wed, Mar 13, 2013 at 02:16:23PM +0100, Andreas Bie?mann wrote:
> Hi Simon,
>
> On 03/13/2013 04:52 AM, Simon Glass wrote:
> > Hi,
> >
> > On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass <sjg@chromium.org> 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.
>
> I tested the whole series on avr32. The minor changes there do not break
> runtime behaviour, therefore
>
> Tested-by: Andreas Bie?mann <andreas.biessmann@googlemail.com>
>
> Will this series be applied for upcomming release? I'm asking cause of
Seeing as there's Wolfgang's tested/ack yes, this is quite likely to go
in. Need to review it all again myself to be sure. Simon, can you
please make a patchwork bundle out of it as well so I can be sure all of
the patches are updated right (ie we have the old ones cleared out
and the new ones assigned to me). Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130313/1c2a557e/attachment.pgp>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
2013-03-13 16:25 ` Tom Rini
@ 2013-03-13 22:20 ` Simon Glass
2013-03-14 17:42 ` Simon Glass
0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2013-03-13 22:20 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Wed, Mar 13, 2013 at 9:25 AM, Tom Rini <trini@ti.com> wrote:
> On Wed, Mar 13, 2013 at 02:16:23PM +0100, Andreas Bie?mann wrote:
>> Hi Simon,
>>
>> On 03/13/2013 04:52 AM, Simon Glass wrote:
>> > Hi,
>> >
>> > On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass <sjg@chromium.org> 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.
>>
>> I tested the whole series on avr32. The minor changes there do not break
>> runtime behaviour, therefore
>>
>> Tested-by: Andreas Bie?mann <andreas.biessmann@googlemail.com>
>>
>> Will this series be applied for upcomming release? I'm asking cause of
>
> Seeing as there's Wolfgang's tested/ack yes, this is quite likely to go
> in. Need to review it all again myself to be sure. Simon, can you
> please make a patchwork bundle out of it as well so I can be sure all of
> the patches are updated right (ie we have the old ones cleared out
> and the new ones assigned to me). Thanks!
I found that one patch (2/31) needed a rev due to a recent change. I
resent this so it should hit patchwork soon.
I did create a bundle but things were in the wrong order, so I will
try again when that happens.
In the meantime there is a tree at u-boot-x86.git branch us-board-v11,
and I can do a pull request if you like.
Regards,
Simon
>
> --
> Tom
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
2013-03-13 22:20 ` Simon Glass
@ 2013-03-14 17:42 ` Simon Glass
0 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2013-03-14 17:42 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Wed, Mar 13, 2013 at 3:20 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Wed, Mar 13, 2013 at 9:25 AM, Tom Rini <trini@ti.com> wrote:
>> On Wed, Mar 13, 2013 at 02:16:23PM +0100, Andreas Bie?mann wrote:
>>> Hi Simon,
>>>
>>> On 03/13/2013 04:52 AM, Simon Glass wrote:
>>> > Hi,
>>> >
>>> > On Mon, Mar 11, 2013 at 10:03 AM, Simon Glass <sjg@chromium.org> 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.
>>>
>>> I tested the whole series on avr32. The minor changes there do not break
>>> runtime behaviour, therefore
>>>
>>> Tested-by: Andreas Bie?mann <andreas.biessmann@googlemail.com>
>>>
>>> Will this series be applied for upcomming release? I'm asking cause of
>>
>> Seeing as there's Wolfgang's tested/ack yes, this is quite likely to go
>> in. Need to review it all again myself to be sure. Simon, can you
>> please make a patchwork bundle out of it as well so I can be sure all of
>> the patches are updated right (ie we have the old ones cleared out
>> and the new ones assigned to me). Thanks!
>
> I found that one patch (2/31) needed a rev due to a recent change. I
> resent this so it should hit patchwork soon.
>
> I did create a bundle but things were in the wrong order, so I will
> try again when that happens.
>
> In the meantime there is a tree at u-boot-x86.git branch us-board-v11,
> and I can do a pull request if you like.
Please see the patchwork bundle here:
http://patchwork.ozlabs.org/bundle/sjg/us-board/
I had to rebase one of the patches and resend to the mailing this. But
I just tried this bundle and it applied cleanly to master for me.
Regards,
Simon
>
> Regards,
> Simon
>
>>
>> --
>> Tom
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
2013-03-13 8:46 ` [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC Wolfgang Denk
@ 2013-03-15 22:23 ` Tom Rini
2013-03-30 21:34 ` Simon Glass
1 sibling, 0 replies; 9+ messages in thread
From: Tom Rini @ 2013-03-15 22:23 UTC (permalink / raw)
To: u-boot
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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130315/da1bf0d1/attachment.pgp>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC
2013-03-13 8:46 ` [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC Wolfgang Denk
2013-03-15 22:23 ` Tom Rini
@ 2013-03-30 21:34 ` Simon Glass
1 sibling, 0 replies; 9+ messages in thread
From: Simon Glass @ 2013-03-30 21:34 UTC (permalink / raw)
To: u-boot
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 at 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-03-30 21:34 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1363021453-6566-1-git-send-email-sjg@chromium.org>
2013-03-11 17:50 ` [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC Simon Glass
2013-03-13 3:52 ` Simon Glass
2013-03-13 13:16 ` Andreas Bießmann
2013-03-13 16:25 ` Tom Rini
2013-03-13 22:20 ` Simon Glass
2013-03-14 17:42 ` Simon Glass
[not found] <1363020460-14307-1-git-send-email-sjg@chromium.org>
2013-03-11 16:49 ` [U-Boot] [PATCH v9 09/31] Introduce generic pre-relocation board_f.c Simon Glass
2013-03-13 8:46 ` [U-Boot] [PATCH v9 0/31] Create generic board init for ARM, x86, PPC Wolfgang Denk
2013-03-15 22:23 ` Tom Rini
2013-03-30 21:34 ` Simon Glass
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox