From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Date: Tue, 05 Jul 2011 00:03:59 +0200 [thread overview]
Message-ID: <4E1238CF.5010104@aribaud.net> (raw)
In-Reply-To: <4E1238A6.8010300@aribaud.net>
Le 05/07/2011 00:03, Albert ARIBAUD a ?crit :
> Hi Harvey,
Sorry Christopher, I mixed up.
> Le 04/07/2011 23:06, Christopher Harvey a ?crit :
>> On Mon, Jul 04, 2011 at 12:00:19PM +0300, Igor Grinberg wrote:
>>> 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<grinberg@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
>>> --
>>> 1.7.3.4
>>>
>> I'm curious, is it a feature that bd->bi_arch_number can be set at
>> runtime? Do any boards actually make a decision about what value to
>> set this to? If not, then maybe it should be a required value. I've
>> submitted some patches that deal with the same sort of issue, so I'm
>> interested in seeing that happens to this one.
>
> Some boards indeed have a feature to set the mach_type at runtime, for
> example to run both the mainline linux kernel and a manufacturer one
> (manufacturers tend to use/expect fancy machine types).
>
> Amicalement,
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-07-04 22:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 9:00 [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation Igor Grinberg
2011-07-04 9:00 ` [U-Boot] [PATCH 2/3] arm: nvidia and smdk6400: use common code for machine type Igor Grinberg
2011-07-04 9:00 ` [U-Boot] [PATCH 3/3] arm: omap: innovator: " Igor Grinberg
2011-07-04 21:06 ` [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation Christopher Harvey
2011-07-04 22:03 ` Albert ARIBAUD
2011-07-04 22:03 ` Albert ARIBAUD [this message]
2011-07-04 22:16 ` Wolfgang Denk
2011-07-05 14:08 ` charvey at matrox.com
2011-07-05 15:12 ` Igor Grinberg
2011-07-05 7:10 ` Igor Grinberg
2011-07-06 18:53 ` Albert ARIBAUD
2011-07-06 20:05 ` Igor Grinberg
2011-07-07 16:07 ` Albert ARIBAUD
2011-07-07 16:51 ` Igor Grinberg
2011-07-07 17:46 ` Albert ARIBAUD
2011-07-07 21:06 ` Igor Grinberg
2011-07-13 5:52 ` Igor Grinberg
2011-07-14 14:10 ` Albert ARIBAUD
2011-07-14 14:20 ` Albert ARIBAUD
2011-07-14 14:57 ` Igor Grinberg
2011-07-14 15:45 ` [U-Boot] [PATCH v2 1/3] arm: add CONFIG_MACH_TYPE setting " Igor Grinberg
2011-07-17 6:56 ` Igor Grinberg
2011-07-17 9:10 ` Albert ARIBAUD
2011-07-17 9:08 ` Albert ARIBAUD
2011-07-27 10:31 ` Chander Kashyap
2011-07-27 13:04 ` Igor Grinberg
2011-07-28 6:41 ` Chander Kashyap
2011-07-28 7:59 ` Igor Grinberg
2011-07-28 8:19 ` Chander Kashyap
2011-07-28 8:58 ` Igor Grinberg
2011-08-04 12:05 ` Albert ARIBAUD
2011-08-11 4:16 ` Chander Kashyap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E1238CF.5010104@aribaud.net \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox