[U-Boot-Users] bootm as a script -- requires HUSH?
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides.
This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else).
is this correct?
- k
Kumar Gala wrote:
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides.
This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else).
is this correct?
- k
Yes.
gvb
On Aug 7, 2008, at 12:21 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides. This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else). is this correct?
- k
Yes.
Than I think the ideas you guys have aren't beneficial to anyone. What benefit to we gain by doing this? Its going to be slower and larger.
- k
Kumar Gala wrote:
On Aug 7, 2008, at 12:21 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides. This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else). is this correct?
- k
Yes.
Than I think the ideas you guys have aren't beneficial to anyone. What benefit to we gain by doing this? Its going to be slower and larger.
- k
...for some subset of "anyone."
A lot of people resisted moving to the linux 2.6 kernel because it is slower and larger than the 2.4 kernel. A lot of embedded devices (and probably some servers and desktops) are still running 2.4 kernels. I would not conclude that 2.6 isn't beneficial to anyone.
Maybe the destination turns into a failure, but half the fun is planning the trip.
gvb
In message BBDD524A-F763-49E1-B459-0EB5AA242A32@kernel.crashing.org you wrote:
Than I think the ideas you guys have aren't beneficial to anyone. What benefit to we gain by doing this? Its going to be slower and larger.
Note: I don't see why it would absolutley be necessary to use hush. My idea is to end up on each target with a board specific, but otherwise simple sequence of calls
We gain much clearer code the function of which can be understood by mere mortals. At least that's the main goal.
Yes, it is going to be slower. But how much? 2 milliseconds? or 5? Or 25? Do you really think it will matter?
And I'm not sure that the code will be significantly larger. We might be able to clean up a thing here and there on the way, there are some areas where code duplication exists.
In any case, I expoect the total numbers of lines of code in U-Boot to go down by quite an amount - for example, if we manage to get rid of all the code duplication we have now across architectures.
Best regards,
Wolfgang Denk
On Aug 7, 2008, at 2:34 PM, Wolfgang Denk wrote:
In any case, I expoect the total numbers of lines of code in U-Boot to go down by quite an amount - for example, if we manage to get rid of all the code duplication we have now across architectures.
I doubt this is really going to happen because the majority of code is specific to the mechanism used to boot a kernel that is arch specific.
(ie, the ePAPR style interface on PPC, the TAGs support on ARM, etc.)
I dont see how we reduce code in that area (since it seems fundamentally arch specific).
- k
In message 45CA6EEB-4A74-46FC-A544-B71C0E922753@kernel.crashing.org you wrote:
On Aug 7, 2008, at 2:34 PM, Wolfgang Denk wrote:
In any case, I expoect the total numbers of lines of code in U-Boot to go down by quite an amount - for example, if we manage to get rid of all the code duplication we have now across architectures.
I doubt this is really going to happen because the majority of code is specific to the mechanism used to boot a kernel that is arch specific.
(ie, the ePAPR style interface on PPC, the TAGs support on ARM, etc.)
I dont see how we reduce code in that area (since it seems fundamentally arch specific).
There is a lot of common code - verify and uncompress the Linux kernel image; check for existence of, then verify and load the ramdisk, etc.
Best regards,
Wolfgang Denk
On Aug 7, 2008, at 3:47 PM, Wolfgang Denk wrote:
In message <45CA6EEB-4A74-46FC-A544- B71C0E922753@kernel.crashing.org> you wrote:
On Aug 7, 2008, at 2:34 PM, Wolfgang Denk wrote:
In any case, I expoect the total numbers of lines of code in U- Boot to go down by quite an amount - for example, if we manage to get rid of all the code duplication we have now across architectures.
I doubt this is really going to happen because the majority of code is specific to the mechanism used to boot a kernel that is arch specific.
(ie, the ePAPR style interface on PPC, the TAGs support on ARM, etc.)
I dont see how we reduce code in that area (since it seems fundamentally arch specific).
There is a lot of common code - verify and uncompress the Linux kernel image; check for existence of, then verify and load the ramdisk, etc.
I agree that there is probably a far amount of code in lib_ppc/bootm.c that can be made common above it.
The ARCH specific bits seem to be the "jump" and the specific mechanism to pass boot information to the kernel (bd_t, fdt, ARM tags, etc).
- k
In message 44343BF5-2E91-4596-8CCA-61CEA1F84F63@kernel.crashing.org you wrote:
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides.
This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else).
is this correct?
I woul like to avoid that, if possible.
Best regards,
Wolfgang Denk
On Aug 7, 2008, at 2:29 PM, Wolfgang Denk wrote:
In message 44343BF5-2E91-4596-8CCA-61CEA1F84F63@kernel.crashing.org you wrote:
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides.
This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else).
is this correct?
I woul like to avoid that, if possible.
Which implies to me the sequence has to be a simple ordered sequence w/ o any if/than/else aspects to it. Am I missing something?
- k
Kumar Gala wrote:
On Aug 7, 2008, at 2:29 PM, Wolfgang Denk wrote:
In message 44343BF5-2E91-4596-8CCA-61CEA1F84F63@kernel.crashing.org you wrote:
if I understand Wolfgang and Jerry they'd like to recode the control flow of the bootm command in the scripting env u-boot provides.
This seems to imply that we'd require HUSH as the simple parser doesn't seem to provide any control statements like (if..then..else).
is this correct?
I woul like to avoid that, if possible.
Which implies to me the sequence has to be a simple ordered sequence w/ o any if/than/else aspects to it. Am I missing something?
- k
Nope.
Remaining to be shown: how far apart "reality" is from "goal".
gvb
"I've always used my ignorance as a weapon. I don't know why things can't be done. Engineers spend a lot of time telling us why things can't be done. Sometimes they're right. But sometimes they're not."
- Garry Hoyt
participants (3)
-
Jerry Van Baren -
Kumar Gala -
Wolfgang Denk