[U-Boot-Users] RE: FT u-boot shim
Would it be possible to have the kernel smart enough that if it gets passed a bd_t pointer, it updates the dts before booting fully. Newer u-boot versions that support dts then would pass a NULL bd_t pointer to a kernel that supports dts. Kernel would then not update the dts, but use the one it gets handed.
bootm should be able to see if the kernel has an attached dts, update it with runtime parameters, and hand it off to the kernel. If it is an old kernel, hand it the bd_t pointer.
On Apr 27, 2006, at 2:30 PM, Rune Torgersen wrote:
Would it be possible to have the kernel smart enough that if it gets passed a bd_t pointer, it updates the dts before booting fully. Newer u-boot versions that support dts then would pass a NULL bd_t pointer to a kernel that supports dts. Kernel would then not update the dts, but use the one it gets handed.
What you are describing is the boot shim method.
U-boot is already capable of effectively doing this. You can set a u- boot environment variable to make bootm do different things if you have flat device tree support built into u-boot.
bootm should be able to see if the kernel has an attached dts, update it with runtime parameters, and hand it off to the kernel. If it is an old kernel, hand it the bd_t pointer.
We can do this w/o too much modification to what is happening in u- boot today. I'd probably like to keep the ability to build a dev tree into the u-boot binary, but make the preferred means to pass a blob into the bootm command.
- kumar
In message 2CD98C5D-E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org you wrote:
We can do this w/o too much modification to what is happening in u- boot today. I'd probably like to keep the ability to build a dev tree into the u-boot binary, but make the preferred means to pass a
I don't like this, as it's a very Linux-centric view, but U-Boot is supposed to be OS unaware and independent.
Best regards,
Wolfgang Denk
On Apr 27, 2006, at 2:45 PM, Wolfgang Denk wrote:
In message <2CD98C5D- E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org> you wrote:
We can do this w/o too much modification to what is happening in u- boot today. I'd probably like to keep the ability to build a dev tree into the u-boot binary, but make the preferred means to pass a
I don't like this, as it's a very Linux-centric view, but U-Boot is supposed to be OS unaware and independent.
Hmm, I guess. There really isn't anything about the device tree that is Linux specific. Other OSes could choice to use it. But lets argue about that one once I've got the mechanism in which we pass the blob in via the bootm command.
The only difference I see would be that the address of the blob would be implicit if the blob was built into u-boot. We would still use a passed in blob via the bootm command if given.
- kumar
In message 9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org you wrote:
Hmm, I guess. There really isn't anything about the device tree that is Linux specific. Other OSes could choice to use it. But lets
I guess there are VxWorks BSP's for most of the boards we are talking about, right? Do they use the device tree? I would be *very* surprised.
Best regards,
Wolfgang Denk
participants (3)
-
Kumar Gala -
Rune Torgersen -
Wolfgang Denk