In message <[EMAIL PROTECTED]> you wrote:
>
> > Well, at the moment we don't do any such clever stuff eihter. We load
> > the kernel low and the ramdisk high. That's all.
> >
> > Do we need more?
>
> Yes. bd_t for old style boot... no idea on non-ppc.
bd_t is already handled as described.
> dtb
>>> Stop, this is not correct. "filesize" gets set when loading the
>>> (compressed) image. It contains the _file_ size, i. e. the sum of
>>> all
>>> included images plus headers etc.
>>>
>>> bootm does not touch filesize.
>>
>> in the method you guys seem to be arguing for we have to return the
In message <[EMAIL PROTECTED]> you wrote:
>
> > I think the average user does not need to now this. He can just run
> the systemn-provided "bootm" command without caring if this is a
> > monolithic pile of unreeadable code, or a wrapper function that
> > sequentially calls out for a l
On Aug 6, 2008, at 3:36 PM, Wolfgang Denk wrote:
> In message <6130E31C-5845-4DCF-
> [EMAIL PROTECTED]> you wrote:
>>
>>> Ooo, that sounds hard. If we are only re-enabling interrupts/usb/
>>> caches it probably is manageable, but my hackles.
>>
>> This is a buyer-beware kinda of situation. Thi
Kumar Gala wrote:
>
> On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:
[snip]
>> Having said that, I was thinking and would advocate pushing
>> functionality out of bootm and into other commands, as appropriate.
>> As an example, bootm doesn't need to do *any* fdt stuff, the "fdt"
>> built
In message <[EMAIL PROTECTED]> you wrote:
>
> > Ooo, that sounds hard. If we are only re-enabling interrupts/usb/
> > caches it probably is manageable, but my hackles.
>
> This is a buyer-beware kinda of situation. Think about a case that we
> are booting a kernel at a location of memory tha
On Aug 6, 2008, at 3:26 PM, Wolfgang Denk wrote:
> In message
> <[EMAIL PROTECTED]> you wrote:
>>
>>> Note that you cannot recover / restore after starting to uncompress
>>> the image, because usually you will overwrite the exception vectors.
>>
>> Normally that is true.. however there are some
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
[snip]
>> Aside: verify should be an image verify command, not a env variable flag
>> (see below). This is probably true of most of the current env
>
> We alreay have a verify command. It's called "imls".
>> variables: the re
In message <[EMAIL PROTECTED]> you wrote:
>
> > Note that you cannot recover / restore after starting to uncompress
> > the image, because usually you will overwrite the exception vectors.
>
> Normally that is true.. however there are some situations that its
> feasible. For example if you are
In message <[EMAIL PROTECTED]> you wrote:
>
> > bootm restore (undo anything prep did, reset state tracking)
>
> Ooo, that sounds hard. If we are only re-enabling interrupts/usb/caches
> it probably is manageable, but my hackles.
ACK. And if we really restore anything, than just interrupts and
On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
>>> Kumar Gala wrote:
here's a rough start at an outline for the bootm script based on
the code (I've only outlined the Linux/PPC boot case its seems
t
On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:
> In message <5E53E387-237D-480E-
> [EMAIL PROTECTED]> you wrote:
>>
>> one idea is having "stages" of bootm handled as sub commands:
>>
>> bootm start
>> bootm prep(disable interrupts, stop usb, disable caches)
> --- Point of no return here
Kumar Gala wrote:
> On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
>
>> Kumar Gala wrote:
>>> here's a rough start at an outline for the bootm script based on
>>> the code (I've only outlined the Linux/PPC boot case its seems the
>>> most complicated). One of the first things we clearly
In message <[EMAIL PROTECTED]> you wrote:
>
> one idea is having "stages" of bootm handled as sub commands:
>
> bootm start
> bootm prep(disable interrupts, stop usb, disable caches)
--- Point of no return here ---
> bootm load_os (decompress OS image)
> bootm load_fdt(relocates fdt to prope
On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> here's a rough start at an outline for the bootm script based on
>> the code (I've only outlined the Linux/PPC boot case its seems the
>> most complicated). One of the first things we clearly need is a
>> imload c
Kumar Gala wrote:
> here's a rough start at an outline for the bootm script based on the
> code (I've only outlined the Linux/PPC boot case its seems the most
> complicated). One of the first things we clearly need is a imload
> command. Thoughts on the various disable_{interrupts, usb, cac
here's a rough start at an outline for the bootm script based on the
code (I've only outlined the Linux/PPC boot case its seems the most
complicated). One of the first things we clearly need is a imload
command. Thoughts on the various disable_{interrupts, usb, caches} ?
- k
bootm script:
17 matches
Mail list logo
