Hi Igor, Le 06/07/2011 22:05, Igor Grinberg a écrit : > On 07/06/11 21:53, Albert ARIBAUD wrote: > >> Hi Igor, >> >> Le 04/07/2011 11:00, Igor Grinberg a écrit : >>> CONFIG_MACH_TYPE can be used to set the machine type number in the >>> common arm code instead of setting it in the board code. >>> >>> Signed-off-by: Igor Grinberg<grinb...@compulab.co.il> >>> --- >>> README | 12 ++++++++++++ >>> arch/arm/lib/board.c | 5 +++++ >>> 2 files changed, 17 insertions(+), 0 deletions(-) >>> >>> diff --git a/README b/README >>> index 446966d..a9ccb0a 100644 >>> --- a/README >>> +++ b/README >>> @@ -442,6 +442,18 @@ The following options need to be configured: >>> crash. This is needed for buggy hardware (uc101) where >>> no pull down resistor is connected to the signal IDE5V_DD7. >>> >>> + CONFIG_MACH_TYPE [relevant for ARM only] >>> + >>> + This option can be used to specify the machine type number >>> + as it appears in the ARM machine registry >>> + (see http://www.arm.linux.org.uk/developer/machines/). >>> + If this option is not defined, then your board code >>> + will have to set this up like: >>> + gd->bd->bi_arch_number =<mach type>; >>> + Note: This option is not suitable if you have multiple >>> + boards supported in a single configuration file and the >>> + machine type is runtime discoverable. >>> + >>> - vxWorks boot parameters: >>> >>> bootvx constructs a valid bootline using the following >>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c >>> index 169dfeb..ee77d05 100644 >>> --- a/arch/arm/lib/board.c >>> +++ b/arch/arm/lib/board.c >>> @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr) >>> >>> monitor_flash_len = _end_ofs; >>> debug ("monitor flash len: %08lX\n", monitor_flash_len); >>> + >>> +#ifdef CONFIG_MACH_TYPE >>> + bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */ >>> +#endif >>> + >>> board_init(); /* Setup chipselects */ >>> >>> #ifdef CONFIG_SERIAL_MULTI >> >> I don't really see the added value of having this configuration option. It >> is used in only one place for one line of code, which is a sign to me that >> it does not bring any substantial benefits. > > Well, this is something that came up when I tried to get rid of machine_is_* > macros (patch 3/3), so we could change/cut/simplify the overgrown mach-types.h > if we want/need to...
You've read and responded to this thread: http://old.nabble.com/-U-Boot--Update-and-Cut-down-mach-types-td31432177.html, so you know that mach-types.h should not be changed, cut or simplified, but should only be generated from the mach-types list pulled from the ARM Linux machine repository just like Linux' mach-types.h is generated (though we use the full list whereas Linux uses a reduced list, because U-Boot supports some ARM machines which Linux does not). If your goal is reducing the size of mach-types.h, there is a branch in u-boot-ti that is about this (Sandeep: has it been posted as patches for review?) > I think there is an added value, may be it is hard to see it right now. If it is hard to see, then maybe it is too small a value to be worth the effort -- that's what I am trying to sort out. > If we have this option and it is documented, then any new board can use it > instead of thinking (although it is simple) where and how to dereference > the bi_arch_number. Not sure I get you there. Can you elaborate on a more precise example that would show the benefits of it? > Also, it can come in handy, in the configuration system (I think it is called > Kbuild?), > so the value can be chosen from the list or something. AFAICT, the Linux build system does fine with the generated mach-type. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
