Skip to contentSkip to conversation

pass custom data to Linux

PATCH New Anders Larsen 4 participants 15 messages Nov 12, 2003 – Jan 2, 2004

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 pass custom data to Linux

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

#1 lore raw

PATCH 1/1 pass custom data to Linux

Quoted 5 lines · Anders Larsen

Hi,

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

Quoted 8 lines

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

Quoted 7 lines

CHANGELOG:
add config option CONFIG_CUSTOM_TAGS

Cheers
Anders

#2 lore raw

PATCH 1/1 pass custom data to Linux

"George G. Davis" <[email protected]> schreibt:

Quoted 8 lines
Quoted 4 lines · Anders Larsen

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

#3 lore raw

PATCH 1/1 pass custom data to Linux

Quoted 13 lines · Anders Larsen

"George G. Davis" <[email protected]> schreibt:

Quoted 9 lines
Quoted 4 lines · Anders Larsen

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?

Quoted 7 lines

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

Quoted 5 lines

Cheers
Anders

#4 lore raw

PATCH 1/1 pass custom data to Linux

"George G. Davis" <[email protected]> schreibt:

Quoted 11 lines
Quoted 5 lines · Anders Larsen

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

#5 lore raw

PATCH 1/1 pass custom data to Linux

Quoted 6 lines · In message <[email protected]> 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?

Quoted 1 line

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

Signature · 4 lines
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.
#6 lore raw

PATCH 1/1 pass custom data to Linux

Wolfgang Denk <[email protected]> schreibt:

Quoted 10 lines
Quoted 6 lines · In message <[email protected]> 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

Quoted 8 lines
Quoted 2 lines

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

#7 lore raw

PATCH 1/1 pass custom data to Linux

Quoted 3 lines · In message <[email protected]> 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?

Quoted 3 lines

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

Signature · 4 lines
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.
#8 lore raw

PATCH 1/1 pass custom data to Linux

Wolfgang Denk <[email protected]> schreibt:

Quoted 7 lines
Quoted 3 lines · In message <[email protected]> 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.

Quoted 2 lines

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

Roger.

Quoted 6 lines

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

#9 lore raw

PATCH 1/1 pass custom data to Linux

Quoted 6 lines · In message <[email protected]> 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

Signature · 4 lines
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
#10 lore raw

PATCH 1/1 pass custom data to Linux

Wolfgang Denk <[email protected]> schreibt:

Quoted 9 lines
Quoted 6 lines · In message <[email protected]> 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

#11 lore raw

PATCH 1/1 pass custom data to Linux

In reply to Anders Larsen

Dear Anders,

Quoted 7 lines · in message <[email protected]> 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

Signature · 6 lines
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
#12 lore raw

PATCH 1/1 pass custom data to Linux

Quoted 11 lines · On Sun, 07 Dec 2003 01:07:42 +0100 Wolfgang Denk <[email protected]> wrote:

Dear Anders,

Quoted 7 lines · in message <[email protected]> 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.

Quoted 5 lines

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

#13 lore raw

PATCH 1/1 pass custom data to Linux

Anders Larsen <[email protected]> schreibt:

Quoted 18 lines · On Sun, 07 Dec 2003 01:07:42 +0100 Wolfgang Denk <[email protected]> wrote:
Quoted 4 lines

Dear Anders,

in message <[email protected]> you

Quoted 12 lines · wrote:
Quoted 7 lines

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.

Quoted 7 lines
Quoted 1 line

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

#14 lore raw

PATCH 1/1 pass custom data to Linux

Quoted 10 lines · In message <[email protected]> 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

Signature · 3 lines
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