[U-Boot-Users] Re: FT u-boot shim
On Apr 26, 2006, at 2:19 PM, Wolfgang Denk wrote:
In message <A8793E99-83C1-4FD9-8735- D2E8F98B3003@kernel.crashing.org> you wrote:
I think thats part of the idea with arch/powerpc defining a standard mechanism for how a boot loader should pass information to the kernel (via a flat device tree).
Yet another standard.
How would you propose that we handle booting arch/powerpc kernels from u-boot going forward? (for new board ports and existing board ports).
Ideally, I'd like to see a common kernel interface for all archi- tectures, PowerPC and ARM and MIPS and ... But last time I dared to suggest this I've been told what a nincompoop I am.
I will accept what is decided by the P.T.B., but I request not to break backwards compatibility with existing systems.
I've been thinking about the various issues related to booting an arch/powerpc kernel via u-boot. I was hoping to get some ideas/ comments on what people thought about the various issues/questions related to producing a system that can boot an arch/powerpc kernel for an embedded system. I'm using u-boot as the boot loader since its a popular choice (I imagine the issues are similar for others):
[NOTE: dts, flat dev tree, etc are used interchangeably]
1. boot with an "old" u-boot (via bd_t): * Have a boot wrapper that takes bd_t and dts and merges them @ runtime * Boot wrapper has to be custom based on bd_t definition for the system * dts owned by kernel??
2. boot with a "new" u-boot (has a .dts in it): * capable of booting arch/powerpc kernel directly w/o modification * in a production system don't want to update u-boot * dts owned by u-boot??
Some questions/issues: * ownership of .dts is problematic. I hate having a file duplicated by both u-boot and kernel. However it also seems bad to make the build of either depend on the user grabbing a dts from some third party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS port. Boards ship with an "old" u-boot, thus we need a kernel wrapper with .dts. However, newer u-boot's can (hopefully will) have a dts in them
* updating of dts: In case 1, this is trivial since its part of the kernel blob. Case 2. is more difficult. What do people think of treating the dts like the environment. You have a version compiled in, but can alternately have a blob in another location that will be used if exists. This would allow one to update the dts portion w/o effecting the actual boot loader.
* one solution to the copies of .dts is that we make the wrapper portion of the kernel the owner of the official latest and greatest .dts. Every so often a maintainer can sync their .dts with u-boot to keep them relatively in sync. However, the main mechanism would be to load the latest .dts blob into the secondary location. We can provide scripts/tools to do this via u-boot and linux.
comments, other issues people have thought of?
- kumar
In message 6E3621C5-A379-4ABC-99C0-9A02B48D525D@kernel.crashing.org Kumar Gala wrote:
- boot with an "old" u-boot (via bd_t):
- Have a boot wrapper that takes bd_t and dts and merges them @ runtime
- Boot wrapper has to be custom based on bd_t definition for the system
- dts owned by kernel??
Since we cannot go back in time and fix the "old" U-Boot this seems to be the only option.
- boot with a "new" u-boot (has a .dts in it):
- capable of booting arch/powerpc kernel directly w/o modification
OK.
- in a production system don't want to update u-boot
Let's say we have to support such situations, too.
- dts owned by u-boot??
I'm not sure about this. I tend to believe the dts belongs to the kernel.
Some questions/issues:
- ownership of .dts is problematic. I hate having a file duplicated
by both u-boot and kernel. However it also seems bad to make the build of either depend on the user grabbing a dts from some third party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS port. Boards ship with an "old" u-boot, thus we need a kernel wrapper with .dts. However, newer u-boot's can (hopefully will) have a dts in them
Can we provide the dts as a separate blob that gets built with the kernel image? From U-Boot's point of view, this could be a multi-file image which combines the dts and the kernel into a single file so that users don't have to care much about this.
- updating of dts: In case 1, this is trivial since its part of the
kernel blob. Case 2. is more difficult. What do people think of treating the dts like the environment. You have a version compiled
I don't like this idea.
in, but can alternately have a blob in another location that will be used if exists. This would allow one to update the dts portion w/o effecting the actual boot loader.
If we consider this, then we might as well combine the dts with the kernel image. Alternatively, the dts might be stored in a separate location in memory. It would be easy to extend the "bootm" command to take an additional argument (dts address).
- one solution to the copies of .dts is that we make the wrapper
portion of the kernel the owner of the official latest and greatest .dts. Every so often a maintainer can sync their .dts with u-boot to keep them relatively in sync. However, the main mechanism would be to load the latest .dts blob into the secondary location.
Why not load it separately or as part of the Linux kernel image?
Best regards,
Wolfgang Denk
Let's say we have to support such situations, too.
- dts owned by u-boot??
I'm not sure about this. I tend to believe the dts belongs to the kernel.
Some questions/issues:
- ownership of .dts is problematic. I hate having a file duplicated
by both u-boot and kernel. However it also seems bad to make the build of either depend on the user grabbing a dts from some third party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS port. Boards ship with an "old" u-boot, thus we need a kernel wrapper with .dts. However, newer u-boot's can (hopefully will) have a dts in them
Can we provide the dts as a separate blob that gets built with the kernel image? From U-Boot's point of view, this could be a multi-file image which combines the dts and the kernel into a single file so that users don't have to care much about this.
The problem is that there are somethings that u-boot knows that needs to go into the blob (memory size, boot args, initrd info, frequencies, etc.)
- updating of dts: In case 1, this is trivial since its part of the
kernel blob. Case 2. is more difficult. What do people think of treating the dts like the environment. You have a version compiled
I don't like this idea.
in, but can alternately have a blob in another location that will be used if exists. This would allow one to update the dts portion w/o effecting the actual boot loader.
If we consider this, then we might as well combine the dts with the kernel image. Alternatively, the dts might be stored in a separate location in memory. It would be easy to extend the "bootm" command to take an additional argument (dts address).
How would we distinguish the bootm command that takes a blob versus the ones we have today?
- one solution to the copies of .dts is that we make the wrapper
portion of the kernel the owner of the official latest and greatest .dts. Every so often a maintainer can sync their .dts with u-boot to keep them relatively in sync. However, the main mechanism would be to load the latest .dts blob into the secondary location.
Why not load it separately or as part of the Linux kernel image?
As stated before, the main issue is doing some runtime fix ups to the blob before its handed to the kernel.
The following pieces of info are setup at runtime that are board specific:
linux,stdout_path cpus/<foo>/clock-frequency cpus/<foo>/timebase-frequency cpus/<foo>/bus-frequency <soc>/pci/bus-range <soc>/bus-frequency <soc>/serial/clock-frequecny <soc>/ethernet/address
We could hand bootm a memory location with a blob and do the fix ups at runtime, we would still have some coupling between the blob and u- boot build. At least the blob wouldn't be built into u-boot.
- kumar
Kumar Gala wrote:
Let's say we have to support such situations, too.
- dts owned by u-boot??
I'm not sure about this. I tend to believe the dts belongs to the kernel.
Some questions/issues:
- ownership of .dts is problematic. I hate having a file duplicated
by both u-boot and kernel. However it also seems bad to make the build of either depend on the user grabbing a dts from some third party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS port. Boards ship with an "old" u-boot, thus we need a kernel wrapper with .dts. However, newer u-boot's can (hopefully will) have a dts in them
Can we provide the dts as a separate blob that gets built with the kernel image? From U-Boot's point of view, this could be a multi-file image which combines the dts and the kernel into a single file so that users don't have to care much about this.
The problem is that there are somethings that u-boot knows that needs to go into the blob (memory size, boot args, initrd info, frequencies, etc.)
[snip]
- kumar
A thought that keeps recurring (but I've suppressed because I don't have time to play...) is that it would be Really Cool[tm] to store the u-boot env variables in a flat tree and then pass the env/tree to linux. It also sounds like a major change & disruption to u-boot :-(. I haven't looked at what it would do to code size either.
U-boot could then be a better OpenBoot than OpenBoot ;-)
gvb
[snip]
A thought that keeps recurring (but I've suppressed because I don't have time to play...) is that it would be Really Cool[tm] to store the u-boot env variables in a flat tree and then pass the env/tree to linux. It also sounds like a major change & disruption to u- boot :-(. I haven't looked at what it would do to code size either.
I believe this is already supported in u-boot as a config option. You can also pass the bd_t to the kernel via the flat dev tree if you want.
- kumar
In message 44511C88.1010107@smiths-aerospace.com you wrote:
A thought that keeps recurring (but I've suppressed because I don't have time to play...) is that it would be Really Cool[tm] to store the u-boot env variables in a flat tree and then pass the env/tree to linux. It
If somebody wants to read the environment variables, you don't need to create a flat tree from it.
Also, it doesn't solve the original problem as most of the informa- tion you need to pass is NOT part of the environment (and shall not become such a part).
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 44511C88.1010107@smiths-aerospace.com you wrote:
A thought that keeps recurring (but I've suppressed because I don't have time to play...) is that it would be Really Cool[tm] to store the u-boot env variables in a flat tree and then pass the env/tree to linux. It
If somebody wants to read the environment variables, you don't need to create a flat tree from it.
Understood. That is why it is Really Cool[tm] rather than Really Useful[tm] ;-)
Also, it doesn't solve the original problem as most of the informa- tion you need to pass is NOT part of the environment (and shall not become such a part).
Best regards, Wolfgang Denk
I agree and disagree with the parenthetical part of your statement. Agree because it _wouldn't_ be a part of u-boot (technically it would be if someone put it in their default env for their specific board, but why would denx.de care?).
Disagree because, while u-boot needs/uses some env variables, engineers/companies/end users are free to add variables and, I dare say, most do. If a given board needs to pass certain non u-boot parameters to linux, it would simply add that to its env (which already happens).
I'm not sure you (Wolfgang and Kumar) are following my thought fully (or my ignorance is showing to everybody but me). The thought is to change the native format of the u-boot environment storage from the key-string/value-string pairs to the flat tree (OpenFirmware) format which still supports the same key-string/value-string capability (but can do more than that).
The advantage, as I see it, is that it would be unifying and thus easier to maintain the common variables (call it the GRand Unifying Flat Tree (GRAFT) ;-). One language (flat tree), no shims, equivalent key/value utility (but a different underlying storage format), no visible difference for the users (but potentially an upgrade challenge for existing boards and env variables).
The disadvantage is that it would be disruptive to u-boot and may cause some bloating and discomfort.
gvb (the naive)
P.S. For the non-USA readers: "may cause some bloating and discomfort" is a standard disclaimer on medicines advertised on TV over here.
On Thursday 27 April 2006 23:40, Jerry Van Baren wrote:
Wolfgang Denk wrote:
In message 44511C88.1010107@smiths-aerospace.com you wrote:
A thought that keeps recurring (but I've suppressed because I don't have time to play...) is that it would be Really Cool[tm] to store the u-boot env variables in a flat tree and then pass the env/tree to linux. It
If somebody wants to read the environment variables, you don't need to create a flat tree from it.
Understood. That is why it is Really Cool[tm] rather than Really Useful[tm] ;-)
Also, it doesn't solve the original problem as most of the informa- tion you need to pass is NOT part of the environment (and shall not become such a part).
Best regards, Wolfgang Denk
I agree and disagree with the parenthetical part of your statement. Agree because it _wouldn't_ be a part of u-boot (technically it would be if someone put it in their default env for their specific board, but why would denx.de care?).
Disagree because, while u-boot needs/uses some env variables, engineers/companies/end users are free to add variables and, I dare say, most do. If a given board needs to pass certain non u-boot parameters to linux, it would simply add that to its env (which already happens).
I'm not sure you (Wolfgang and Kumar) are following my thought fully (or my ignorance is showing to everybody but me). The thought is to change the native format of the u-boot environment storage from the key-string/value-string pairs to the flat tree (OpenFirmware) format which still supports the same key-string/value-string capability (but can do more than that).
The advantage, as I see it, is that it would be unifying and thus easier to maintain the common variables (call it the GRand Unifying Flat Tree (GRAFT) ;-). One language (flat tree), no shims, equivalent key/value utility (but a different underlying storage format), no visible difference for the users (but potentially an upgrade challenge for existing boards and env variables).
The disadvantage is that it would be disruptive to u-boot and may cause some bloating and discomfort.
gvb (the naive)
P.S. For the non-USA readers: "may cause some bloating and discomfort" is a standard disclaimer on medicines advertised on TV over here.
Since I'm the guy responsible let me weigh in a bit.
For starters, yes it's possible to pass the whole env using the FT tree. Use CONFIG_OF_HAS_UBOOT_ENV to pass the u-boot env to the FT tree.
As for the rest of the cat-fight, I'm afraid I don't have the energy to jump in at the moment.
Perhaps tomorrow :)
Regards
Pantelis
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[Removed the linuxppc-dev address; this is off topic there.]
In message 44512C25.2080105@smiths-aerospace.com you wrote:
Disagree because, while u-boot needs/uses some env variables, engineers/companies/end users are free to add variables and, I dare say, most do. If a given board needs to pass certain non u-boot parameters to linux, it would simply add that to its env (which already happens).
Yes, of course. But we are talking about parameters like memory sizes, bank start addresses, clock frequencies and that stuff. You don't want to have this in your environment. At least not in the environment we have today.
Of course we can discuss a more structured approach with certain "system" variables, which are not stored in flash, but autogenerated, etc. But this is a different story.
I'm not sure you (Wolfgang and Kumar) are following my thought fully (or my ignorance is showing to everybody but me). The thought is to change the native format of the u-boot environment storage from the key-string/value-string pairs to the flat tree (OpenFirmware) format which still supports the same key-string/value-string capability (but can do more than that).
I see three serious problems with such an approach:
* memory footprint (both code and data size) * boot time * backward compatibility
For example, there are systems in the field which use a 1 kB or 2 kB EEPROM on a slow I2C bus to store the environment (and a 128 kB ROM for the U-Boot code). The current format works well with such systems. How much of this is left if you switch to OFT format?
The advantage, as I see it, is that it would be unifying and thus easier to maintain the common variables (call it the GRand Unifying Flat Tree (GRAFT) ;-). One language (flat tree), no shims, equivalent key/value
I guess you cannot convince me before you can show that Linux on ARM and MIPS (or at least *one* of these) will accept this, too.
The disadvantage is that it would be disruptive to u-boot and may cause some bloating and discomfort.
Grrrlp.
Best regards,
Wolfgang Denk
In message D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org you wrote:
The problem is that there are somethings that u-boot knows that needs to go into the blob (memory size, boot args, initrd info, frequencies, etc.)
Yes. Can we append auch variable data to the fixed part of the dts?
How would we distinguish the bootm command that takes a blob versus the ones we have today?
Arg count. For example:
OLD: bootm <kernel_addr> or bootm <kernel_addr> <ramdisk_addr>
NEW: bootm <kernel_addr> - <dts_addr> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
As stated before, the main issue is doing some runtime fix ups to the blob before its handed to the kernel.
Let's do exactly this: runtime fix ups.
We could hand bootm a memory location with a blob and do the fix ups at runtime, we would still have some coupling between the blob and u- boot build. At least the blob wouldn't be built into u-boot.
OK.
Best regards,
Wolfgang Denk
On Apr 27, 2006, at 2:40 PM, Wolfgang Denk wrote:
In message D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org you wrote:
The problem is that there are somethings that u-boot knows that needs to go into the blob (memory size, boot args, initrd info, frequencies, etc.)
Yes. Can we append auch variable data to the fixed part of the dts?
appending is not really how it works, but the runtime fixup is doable.
How would we distinguish the bootm command that takes a blob versus the ones we have today?
Arg count. For example:
OLD: bootm <kernel_addr> or bootm <kernel_addr> <ramdisk_addr>
NEW: bootm <kernel_addr> - <dts_addr> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
As stated before, the main issue is doing some runtime fix ups to the blob before its handed to the kernel.
Let's do exactly this: runtime fix ups.
We could hand bootm a memory location with a blob and do the fix ups at runtime, we would still have some coupling between the blob and u- boot build. At least the blob wouldn't be built into u-boot.
OK.
Let me play with this some now that I've got some direction.
- kumar
How would we distinguish the bootm command that takes a blob versus the ones we have today?
Arg count. For example:
OLD: bootm <kernel_addr> or bootm <kernel_addr> <ramdisk_addr>
NEW: bootm <kernel_addr> - <dts_addr> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
do you mean a literal '-' char for the no ramdisk, but dts case?
- kumar
In message 7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org you wrote:
NEW: bootm <kernel_addr> - <dts_addr> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
do you mean a literal '-' char for the no ramdisk, but dts case?
Yes. We could write "bootm <kernel_addr> NULL <dts_addr>" or "bootm <kernel_addr> none <dts_addr>" or anythingl ike that as well, but I'm a lazy typist :-)
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org you wrote:
The problem is that there are somethings that u-boot knows that needs to go into the blob (memory size, boot args, initrd info, frequencies, etc.)
Yes. Can we append auch variable data to the fixed part of the dts?
How would we distinguish the bootm command that takes a blob versus the ones we have today?
Arg count. For example:
OLD: bootm <kernel_addr> or bootm <kernel_addr> <ramdisk_addr>
NEW: bootm <kernel_addr> - <dts_addr> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
How would you like to handle the case when dts is packed into multi-image file? Is bootm going to assume that the 3rd Image is dts?
Since dts is tightly coupled to kernel I would prefer something like:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
Best regards, Tolunay
[linuxppc-dev removed, this is off topic there.]
In message 44513DC1.8040608@orkun.us you wrote:
How would you like to handle the case when dts is packed into multi-image file? Is bootm going to assume that the 3rd Image is dts?
With Ramdisk: kernel is 1st, ramdisk is 2nd, and dts is an optional 3rd file. Without ramdisk: kernel is 1st, and dts is an optional 2nd file.
The image type will be used to find out what is what.
Since dts is tightly coupled to kernel I would prefer something like:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
That would be an option, too, but I think my proposal is easier to remember, especially when thinking of the multi-file image case.
Best regards,
Wolfgang Denk
On Friday 28 April 2006 01:12, Wolfgang Denk wrote:
[linuxppc-dev removed, this is off topic there.]
In message 44513DC1.8040608@orkun.us you wrote:
How would you like to handle the case when dts is packed into multi-image file? Is bootm going to assume that the 3rd Image is dts?
With Ramdisk: kernel is 1st, ramdisk is 2nd, and dts is an optional 3rd file. Without ramdisk: kernel is 1st, and dts is an optional 2nd file.
The image type will be used to find out what is what.
Since dts is tightly coupled to kernel I would prefer something like:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
That would be an option, too, but I think my proposal is easier to remember, especially when thinking of the multi-file image case.
It won't work.
The blob must contain the ethernet mac addresses for example...
Best regards,
Wolfgang Denk
Regards
Pantelis
In message 200604280128.28841.pantelis@embeddedalley.com you wrote:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
That would be an option, too, but I think my proposal is easier to remember, especially when thinking of the multi-file image case.
It won't work.
The blob must contain the ethernet mac addresses for example...
Ummm... I'm not sure what you are referring to.
The current topic of the discussion (which format to use for an extended "bootm" command) has obviously no relation to your statement.
And that the static blob that comes with the kernel image must be "fixed up" (which means that board specific parameters like memory size, clock frequencies and MAC addresses must be added/inserted/ap- pended/whatever) has been discussed before.
So what exactly do you mean?
Best regards,
Wolfgang Denk
On Friday 28 April 2006 01:55, Wolfgang Denk wrote:
In message 200604280128.28841.pantelis@embeddedalley.com you wrote:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
That would be an option, too, but I think my proposal is easier to remember, especially when thinking of the multi-file image case.
It won't work.
The blob must contain the ethernet mac addresses for example...
Ummm... I'm not sure what you are referring to.
The current topic of the discussion (which format to use for an extended "bootm" command) has obviously no relation to your statement.
And that the static blob that comes with the kernel image must be "fixed up" (which means that board specific parameters like memory size, clock frequencies and MAC addresses must be added/inserted/ap- pended/whatever) has been discussed before.
So what exactly do you mean?
You're going to carry around all the FT node building code & then patch an external binary blob? Or are you going to poke at hardcoded positions in the blob?
And that with an extra binary blob that you have to carry around, at yet another danger of screwing up. How many posts in the list we're going to get from users that are trying to boot with a blob for their eval board, or worse "something they found in the internet"?
IMHO all this talk about having shims is bunk. It is trivial for the running kernel to detect that a valid BLOB was passed by the bootloader. It can then proceed with using a preset compiled in tree for use with non OF firmware.
But the bootloader should pass & generate the tree, if the board maintainer is willing to pay the cost.
Best regards,
Wolfgang Denk
Regards
Pantelis
In message 200604281034.26439.pantelis@embeddedalley.com you wrote:
You're going to carry around all the FT node building code & then patch an external binary blob? Or are you going to poke at hardcoded positions in the blob?
I think that binary patching of pre-defined addresses is a bad thing to do, as it would soon cause more trouble and incompatibilities than we have right now. So the only remaining option is ...
And that with an extra binary blob that you have to carry around, at yet another danger of screwing up. How many posts in the list we're going to get from users that are trying to boot with a blob for their eval board, or worse "something they found in the internet"?
How many messages do we get today from user who misconfigured their system?
If the kernel make rules create a single file (a multi-file imagew with the kernel and the dts) then I don;t see much changes from the user's point of view.
IMHO all this talk about having shims is bunk. It is trivial for the running kernel to detect that a valid BLOB was passed by the bootloader. It can then proceed with using a preset compiled in tree for use with non OF firmware.
So you vote for keeping duplicated versions of the dts both in U-Boot and in Linux?
But the bootloader should pass & generate the tree, if the board maintainer is willing to pay the cost.
And what is your suggestion if he is not willing to do that?
Best regards,
Wolfgang Denk
On Friday 28 April 2006 10:43, Wolfgang Denk wrote:
In message 200604281034.26439.pantelis@embeddedalley.com you wrote:
You're going to carry around all the FT node building code & then patch an external binary blob? Or are you going to poke at hardcoded positions in the blob?
I think that binary patching of pre-defined addresses is a bad thing to do, as it would soon cause more trouble and incompatibilities than we have right now. So the only remaining option is ...
And that with an extra binary blob that you have to carry around, at yet another danger of screwing up. How many posts in the list we're going to get from users that are trying to boot with a blob for their eval board, or worse "something they found in the internet"?
How many messages do we get today from user who misconfigured their system?
Too many. If there's a way to screw up, users will tend to find it. It's better to not have *any* way to screw up.
If the kernel make rules create a single file (a multi-file imagew with the kernel and the dts) then I don;t see much changes from the user's point of view.
IMHO all this talk about having shims is bunk. It is trivial for the running kernel to detect that a valid BLOB was passed by the bootloader. It can then proceed with using a preset compiled in tree for use with non OF firmware.
So you vote for keeping duplicated versions of the dts both in U-Boot and in Linux?
I vote for having it in u-boot only. The linux blob will be present only for kernels with a requirement to boot on non-OF firmware.
But the bootloader should pass & generate the tree, if the board maintainer is willing to pay the cost.
And what is your suggestion if he is not willing to do that?
Pay the cost in linux kernel size, for the Linux included blob size. Or use an earlier version of the kernel, with all that this entails.
Best regards,
Wolfgang Denk
Regards
Pantelis
shameless question: What are "FT" && "blob" ? Are they big things? In other word, are they "MUST Understand"?
In message 200604281103.32689.pantelis@embeddedalley.com you wrote:
It's better to not have *any* way to screw up.
Indeed. I wonder why there are so many :-(
So you vote for keeping duplicated versions of the dts both in U-Boot and in Linux?
I vote for having it in u-boot only. The linux blob will be present only for kernels with a requirement to boot on non-OF firmware.
This will be some boards. SO we would have some boards where the dts is in U-Boot, and some others were it is in the Linux kernel? And if you want to use a board with different boot loaders, then...
...then we have a mess.
Pay the cost in linux kernel size, for the Linux included blob size.
Agreed.
Or use an earlier version of the kernel, with all that this entails.
I think cutting off support for recent kernel versions is the worst thing we could do.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
So you vote for keeping duplicated versions of the dts both in U-Boot and in Linux?
I vote for having it in u-boot only. The linux blob will be present only for kernels with a requirement to boot on non-OF firmware.
This will be some boards. SO we would have some boards where the dts is in U-Boot, and some others were it is in the Linux kernel? And if you want to use a board with different boot loaders, then...
...then we have a mess.
Why can't we have dts compiled into 'vmlinux' perhaps marked as __init (or something like it). If kernel is going to patch it anyway, why do we pass a static file from u-boot?
I guess OF based system can omit compiling the dts into 'vmlinux' or if bootlooder passes a tree compiled in dts would be ignored/freed if present.
Best regards, Tolunay
On fredag 28 april 2006 00.12, Wolfgang Denk wrote:
[linuxppc-dev removed, this is off topic there.]
In message 44513DC1.8040608@orkun.us you wrote:
How would you like to handle the case when dts is packed into multi-image file? Is bootm going to assume that the 3rd Image is dts?
With Ramdisk: kernel is 1st, ramdisk is 2nd, and dts is an optional 3rd file. Without ramdisk: kernel is 1st, and dts is an optional 2nd file.
The image type will be used to find out what is what.
Since dts is tightly coupled to kernel I would prefer something like:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
That would be an option, too, but I think my proposal is easier to remember, especially when thinking of the multi-file image case.
Hmm... ramdisk_addr (initrd) Isn't the dts supposed to have some file structure?
Suppose we do not have a ramdisk then we could create a ramdisk containing dts information.
If we have a ramdisk couldn't it be patched to contain dts information?
I know to little about this ramdisk will it be discarded to early? Does it have to contain something U-Boot can not provide if used?
/RogerL
[snip]
Hmm... ramdisk_addr (initrd) Isn't the dts supposed to have some file structure?
Suppose we do not have a ramdisk then we could create a ramdisk containing dts information.
If we have a ramdisk couldn't it be patched to contain dts information?
I know to little about this ramdisk will it be discarded to early? Does it have to contain something U-Boot can not provide if used?
This will not work. The "dts" has to get patched up before being handed to the kernel. It contains information like memory size, boot args, initrd locations (if you have a ramdisk), etc.
Building it into the kernel or a ramdisk doesn't work. The fix ups need to occur before the kernel gets ahold of it. So you either do it as a boot wrapper around the kernel which translates the bd_t, and other args into the dts or u-boot does it as part of the bootm command.
- kumar
In message 200604281836.06731.roger.larsson@norran.net you wrote:
Suppose we do not have a ramdisk then we could create a ramdisk containing dts information.
If we have a ramdisk couldn't it be patched to contain dts information?
"could", maybe. But this would break compatibility with existing systems. And I don't see any advantages of such an approach.
I know to little about this ramdisk will it be discarded to early?
No. It may stay and serve as root file system as long as the system is running (= forever).
Does it have to contain something U-Boot can not provide if used?
Can't parse this. When the ramdisk is used (by the Linux kernel), there is no trace of U-Boot left.
Best regards,
Wolfgang Denk
participants (7)
-
??? -
Jerry Van Baren -
Kumar Gala -
Pantelis Antoniou -
Roger Larsson -
Tolunay Orkun -
Wolfgang Denk