[U-Boot-Users] bootm as a script -- requires HUSH?

[U-Boot-Users] bootm as a script -- requires HUSH?

[Kumar Gala]

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

[U-Boot-Users] bootm as a script -- requires HUSH?

[Jerry Van Baren]

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

[U-Boot-Users] bootm as a script -- requires HUSH?

[Kumar Gala]

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

[U-Boot-Users] bootm as a script -- requires HUSH?

[Jerry Van Baren]

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

[U-Boot-Users] bootm as a script -- requires HUSH?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Life would be so much easier if we could  just  look  at  the  source
code.                                                   -- Dave Olson

[U-Boot-Users] bootm as a script -- requires HUSH?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you can't beat it or corrupt it, you pretend it was your  idea  in
the first place.                 - Terry Pratchett, _Guards! Guards!_

[U-Boot-Users] bootm as a script -- requires HUSH?

[Kumar Gala]

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

[U-Boot-Users] bootm as a script -- requires HUSH?

[Kumar Gala]

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

[U-Boot-Users] bootm as a script -- requires HUSH?

[Jerry Van Baren]

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

[U-Boot-Users] bootm as a script -- requires HUSH?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In general, if you think something isn't in Perl, try it out, because
it usually is :-) - Larry Wall in <1991Jul31.174523.9447@netlabs.com>

[U-Boot-Users] bootm as a script -- requires HUSH?

[Kumar Gala]

On Aug 7, 2008, at 3:47 PM, Wolfgang Denk wrote:

> In message <45CA6EEB-4A74-46FC-A544- 
> B71C0E922753 at 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