[U-Boot-Users] [PATCH] 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
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
"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
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
"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
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
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
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
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
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
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
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
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
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
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
participants (4)
-
Anders Larsen -
Anders Larsen -
George G. Davis -
Wolfgang Denk