[U-Boot-Users] [PATCH] pass custom data to Linux

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

Hi,

the attached patch defines a new config option CONFIG_CUSTOM_TAGS for
ARM targets.

Defining this option causes do_bootm_linux() to call the function
setup_custom_tags(), which should be supplied from the board-specific
stuff.

Specifically, I need to pass the board revision and serial number to
the Linux kernel, and I'd like to use the standard method of passing
tagged parameters. For my purpose, ATAG_SERIAL and ATAG_REVISION are
already defined (and supported by the kernel).

CHANGELOG:
   add config option CONFIG_CUSTOM_TAGS

Cheers
 Anders

-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot.custom-tags.patch
Type: application/octet-stream
Size: 1280 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20031112/06b89267/attachment.obj 

[U-Boot-Users] [PATCH] pass custom data to Linux

[George G. Davis]

Anders Larsen wrote:
> Hi,
> 
> the attached patch defines a new config option CONFIG_CUSTOM_TAGS for
> ARM targets.
> 
> Defining this option causes do_bootm_linux() to call the function
> setup_custom_tags(), which should be supplied from the board-specific
> stuff.
> 
> Specifically, I need to pass the board revision and serial number to
> the Linux kernel, and I'd like to use the standard method of passing
> tagged parameters. For my purpose, ATAG_SERIAL and ATAG_REVISION are
> already defined (and supported by the kernel).

Since you say you are using standard ARM Linux tags to do this, why not
just add support for CONFIG_{REVISION,SERIAL}_TAG in lib_arm/armlinux.c?

--
Regards,
George

> 
> CHANGELOG:
>    add config option CONFIG_CUSTOM_TAGS
> 
> Cheers
>  Anders
> 

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

"George G. Davis" <davis_g@comcast.net> schreibt:
>Anders Larsen wrote:
>> Specifically, I need to pass the board revision and serial number to
>> the Linux kernel, and I'd like to use the standard method of passing
>> tagged parameters. For my purpose, ATAG_SERIAL and ATAG_REVISION are
>> already defined (and supported by the kernel).
>
>Since you say you are using standard ARM Linux tags to do this, why not
>just add support for CONFIG_{REVISION,SERIAL}_TAG in lib_arm/armlinux.c?

Hi George,

the tags are standard, but by nature the information is board-specific,
so I don't see how lib_arm/armlinux.c could do much more than simply
calling a function from the board tree.
Do you think my idea of adding the hook setup_custom_tags() is _too_
generic?

Cheers
 Anders

[U-Boot-Users] [PATCH] pass custom data to Linux

[George G. Davis]

Anders Larsen wrote:
> "George G. Davis" <davis_g@comcast.net> schreibt:
> 
>>Anders Larsen wrote:
>>
>>>Specifically, I need to pass the board revision and serial number to
>>>the Linux kernel, and I'd like to use the standard method of passing
>>>tagged parameters. For my purpose, ATAG_SERIAL and ATAG_REVISION are
>>>already defined (and supported by the kernel).
>>
>>Since you say you are using standard ARM Linux tags to do this, why not
>>just add support for CONFIG_{REVISION,SERIAL}_TAG in lib_arm/armlinux.c?
> 
> 
> Hi George,
> 
> the tags are standard, but by nature the information is board-specific,
> so I don't see how lib_arm/armlinux.c could do much more than simply
> calling a function from the board tree.
> Do you think my idea of adding the hook setup_custom_tags() is _too_
> generic?

Perhaps we can use environment variables to initialise those common
tags in armlinux.c. Those environment variable can then be uniquely
initialised/defined in whatever way makes sense for a given target
port?

--
Regards,
George

> 
> Cheers
>  Anders
> 
> 

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

"George G. Davis" <davis_g@comcast.net> schreibt:
>Anders Larsen wrote:
>> the tags are standard, but by nature the information is board-specific,
>> so I don't see how lib_arm/armlinux.c could do much more than simply
>> calling a function from the board tree.
>> Do you think my idea of adding the hook setup_custom_tags() is _too_
>> generic?
>
>Perhaps we can use environment variables to initialise those common
>tags in armlinux.c. Those environment variable can then be uniquely
>initialised/defined in whatever way makes sense for a given target
>port?

Another solution could be to add two fields to struct bd_info, e.g.
bi_sernum and bi_revision, possibly "protected" by
#ifdef CONFIG_SERNUM_TAG and #ifdef CONFIG_REVISION_TAG
(bi_sernum is already defined similarly for at least the NX823),
and have armlinux pass those to the kernel.
The board-specific code would be responsible for filling those fields

This is arguably a cleaner solution than my generic hook.

Wolfgang, what do you think?

Cheers
 Anders

[U-Boot-Users] [PATCH] pass custom data to Linux

[Wolfgang Denk]

In message <fc.004c4e48001e7bee004c4e48001e648f.1e7c14@rea.de> you wrote:
>
> Another solution could be to add two fields to struct bd_info, e.g.
> bi_sernum and bi_revision, possibly "protected" by
> #ifdef CONFIG_SERNUM_TAG and #ifdef CONFIG_REVISION_TAG
> (bi_sernum is already defined similarly for at least the NX823),
> and have armlinux pass those to the kernel.

How would you do this, then?  To  pass  this  information  you  would
probably create the custom tags discussed earlier, right?

> This is arguably a cleaner solution than my generic hook.

I'm not so sure. Keep in mind that the bd_info structure  comes  from
the  PowerPC architecture, wher eit is (more or less directly) passed
to the Linux kernel. For ARM it is not such a natural thing  to  use.
And  in  the  long run (when PPC finally starts using bi_recs) it may
disappear there, too.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The human race is faced with a cruel choice: work  or  daytime  tele-
vision.

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>In message <fc.004c4e48001e7bee004c4e48001e648f.1e7c14@rea.de> you wrote:
>>
>> Another solution could be to add two fields to struct bd_info, e.g.
>> bi_sernum and bi_revision, possibly "protected" by
>> #ifdef CONFIG_SERNUM_TAG and #ifdef CONFIG_REVISION_TAG
>> (bi_sernum is already defined similarly for at least the NX823),
>> and have armlinux pass those to the kernel.
>
>How would you do this, then?  To  pass  this  information  you  would
>probably create the custom tags discussed earlier, right?

Hi Wolfgang,

I'd use the standard tags ATAG_SERIAL and ATAG_REVISION and add
corresponding setup_*_tag() functions to armlinux.c
>
>> This is arguably a cleaner solution than my generic hook.
>
>I'm not so sure. Keep in mind that the bd_info structure  comes  from
>the  PowerPC architecture, wher eit is (more or less directly) passed
>to the Linux kernel. For ARM it is not such a natural thing  to  use.
>And  in  the  long run (when PPC finally starts using bi_recs) it may
>disappear there, too.

Oh, I wasn't aware that bd_info is going to be obsoleted.
Well, how about (ab)using the environment variables serial# and
e.g. revision# for the purpose and leave bd_info alone.
The only problem I see here is that the environment variables can hold
arbitrary strings, whereas the ATAGs expect a 32-bit binary value.

Cheers
 Anders

[U-Boot-Users] [PATCH] pass custom data to Linux

[Wolfgang Denk]

In message <fc.004c4e48001e7c8b3b9aca005d326fbc.1e7c9e@rea.de> you wrote:
>
> I'd use the standard tags ATAG_SERIAL and ATAG_REVISION and add
> corresponding setup_*_tag() functions to armlinux.c

I must be missing something. If you are going to crate standard  tags
anyway, why do you need any special code or storage?

> Oh, I wasn't aware that bd_info is going to be obsoleted.
> Well, how about (ab)using the environment variables serial# and
> e.g. revision# for the purpose and leave bd_info alone.

No. Please don't mess with established standard meanings of variables.

Also, I don't see why such a variable would  be  needed.  Envrionment
variables are intended for interaction with the user, but not to hold
information which is used only internally within U-Boot. For example,
guess  why we don't have an environment variable which gives the size
of the flash memory?


Why do you need additional storage for your data? If you can fill  in
the  values  when  setting  up  the  bd_infor structore or when auto-
creating some environment variables you should also be able  to  fill
in  the same values when generating the ATAG_SERIAL and ATAG_REVISION
tags?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Real computer scientists don't comment their  code.  The  identifiers
are so long they can't afford the disk space.

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>In message <fc.004c4e48001e7c8b3b9aca005d326fbc.1e7c9e@rea.de> you wrote:
>>
>> I'd use the standard tags ATAG_SERIAL and ATAG_REVISION and add
>> corresponding setup_*_tag() functions to armlinux.c
>
>I must be missing something. If you are going to crate standard  tags
>anyway, why do you need any special code or storage?

Since the setup_*_tag() functions live in the generic
lib_arm/armlinux.c I need some way to pass the board-specific info.
I thought bd_info were the right place to do this.
>
>No. Please don't mess with established standard meanings of variables.

Roger.
>
>Why do you need additional storage for your data? If you can fill  in
>the  values  when  setting  up  the  bd_infor structore or when auto-
>creating some environment variables you should also be able  to  fill
>in  the same values when generating the ATAG_SERIAL and ATAG_REVISION
>tags?

Okay then, how about declaring the functions setup_serial_tag()
and setup_revision_tag() in e.g. include/asm-arm/u-boot-arm.h
and having the board-specific code define them?
lib-arm/armlinux.c would then call them if CONFIG_SERIAL_TAG or
CONFIG_REVISION_TAG, resp, are defined.

Cheers
 Anders

[U-Boot-Users] [PATCH] pass custom data to Linux

[Wolfgang Denk]

In message <fc.004c4e48001e7daf3b9aca00acccc0da.1e7dd2@rea.de> you wrote:
>
> Okay then, how about declaring the functions setup_serial_tag()
> and setup_revision_tag() in e.g. include/asm-arm/u-boot-arm.h
> and having the board-specific code define them?
> lib-arm/armlinux.c would then call them if CONFIG_SERIAL_TAG or
> CONFIG_REVISION_TAG, resp, are defined.

Sounds OK to me.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Witch!  Witch!  They'll burn ya!
	-- Hag, "Tomorrow is Yesterday", stardate unknown

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>In message <fc.004c4e48001e7daf3b9aca00acccc0da.1e7dd2@rea.de> you wrote:
>>
>> Okay then, how about declaring the functions setup_serial_tag()
>> and setup_revision_tag() in e.g. include/asm-arm/u-boot-arm.h
>> and having the board-specific code define them?
>> lib-arm/armlinux.c would then call them if CONFIG_SERIAL_TAG or
>> CONFIG_REVISION_TAG, resp, are defined.
>
>Sounds OK to me.

Hi Wolfgang,

in order to implement the above I have to touch
include/asm-arm/u-boot-arm.h which was also modified by my
(not (yet?) accepted) ARM memory-layout patch from last wednesday.

How should I handle this?

Cheers
 Anders

[U-Boot-Users] [PATCH] pass custom data to Linux

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001e648f004c4e48001e648f.1e6494@rea.de> you wrote:
> 
> the attached patch defines a new config option CONFIG_CUSTOM_TAGS for
> ARM targets.
> 
> Defining this option causes do_bootm_linux() to call the function
> setup_custom_tags(), which should be supplied from the board-specific
> stuff.

There was some discussion on the list about this patch, and I somehow
expected to receive an updated / modified version for  it.  But  then
the discussion dried out, and nothing happened.

What's the current state of this? Is there still a patch to add?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I thought my people would grow tired of killing. But you were  right,
they  see it is easier than trading. And it has its pleasures. I feel
it myself. Like the hunt, but with richer rewards.
	-- Apella, "A Private Little War", stardate 4211.8

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

On Sun, 07 Dec 2003 01:07:42 +0100 Wolfgang Denk <wd@denx.de> wrote:

> Dear Anders,
> 
> in message <fc.004c4e48001e648f004c4e48001e648f.1e6494@rea.de> you wrote:
> > 
> > the attached patch defines a new config option CONFIG_CUSTOM_TAGS for
> > ARM targets.
> > 
> > Defining this option causes do_bootm_linux() to call the function
> > setup_custom_tags(), which should be supplied from the board-specific
> > stuff.
> 
> There was some discussion on the list about this patch, and I somehow
> expected to receive an updated / modified version for  it.  But  then
> the discussion dried out, and nothing happened.
> 
> What's the current state of this? Is there still a patch to add?

Hi Wolfgang,

I'll provide a fresh patch rsn - I put it on hold, since you appeared to be
overloaded at the time...

Cheers
 Anders

[U-Boot-Users] [PATCH] pass custom data to Linux

[Anders Larsen]

Anders Larsen <al@alarsen.net> schreibt:
>On Sun, 07 Dec 2003 01:07:42 +0100 Wolfgang Denk <wd@denx.de> wrote:
>
>> Dear Anders,
>> 
>> in message <fc.004c4e48001e648f004c4e48001e648f.1e6494@rea.de> you
>wrote:
>> > 
>> > the attached patch defines a new config option CONFIG_CUSTOM_TAGS for
>> > ARM targets.
>> > 
>> > Defining this option causes do_bootm_linux() to call the function
>> > setup_custom_tags(), which should be supplied from the board-specific
>> > stuff.
>> 
>> There was some discussion on the list about this patch, and I somehow
>> expected to receive an updated / modified version for  it.  But  then
>> the discussion dried out, and nothing happened.
>> 
>> What's the current state of this? Is there still a patch to add?
>
>Hi Wolfgang,
>
>I'll provide a fresh patch rsn - I put it on hold, since you appeared to
>be
>overloaded at the time...

Hi Wolfgang,

the attached patch (against CVS of last night) adds two configuration
options: CONFIG_SERIAL_TAG and CONFIG_REVISION_TAG
These options enable the functions setup_serial_tag() and
setup_revision_tag(), which should be defined in the board-specific
code when needed.

This provides a hook to pass ATAG_SERIAL (board serial number) and
ATAG_REVISION (board revision) to the (ARM) kernel.
These values appear in /proc/cpuinfo of the target.

Furthermore, the patch removes some redundant #defines from
lib_arm/armlinux.c: tag_size(), tag_next() and ATAG_INITRD2 are all
defined (unconditionally) in asm-arm/setup.h

CHANGELOG:
 * add configuration options CONFIG_SERIAL_TAG and CONFIG_REVISION_TAG
   to pass ATAG_SERIAL and ATAG_REVISION, resp., to the ARM target

Cheers
 Anders

-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-1.0.0.tags.patch
Type: application/octet-stream
Size: 2853 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20031208/eb1d45a8/attachment.obj 

[U-Boot-Users] [PATCH] pass custom data to Linux

[Wolfgang Denk]

In message <fc.004c4e48001f0f90004c4e48001e648f.1f0fa9@rea.de> you wrote:
> 
> the attached patch (against CVS of last night) adds two configuration
> options: CONFIG_SERIAL_TAG and CONFIG_REVISION_TAG
> These options enable the functions setup_serial_tag() and
> setup_revision_tag(), which should be defined in the board-specific
> code when needed.
> 
> This provides a hook to pass ATAG_SERIAL (board serial number) and
> ATAG_REVISION (board revision) to the (ARM) kernel.
> These values appear in /proc/cpuinfo of the target.

Thanks, added.

Best regards, and a Happy New Year!

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"It's when they say 2 + 2 = 5 that I begin to argue."    - Eric Pepke