Re: [U-Boot-Users] outline of bootm script
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 command. Thoughts on the various disable_{interrupts, usb,
caches} ?
- k
Another rough start on an outline (only cmd_bootm.c, need to add
image.c information):
http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm
Goal is to identify the major pieces of the sequence, identify what
commands we have and what we need to make a scripted equivalent
sequence for (ultimately) each path through the sequence.
I added a few bullets about functionality I'd like to see the new
sequence to be capable of it.
one idea is having stages of bootm handled as sub commands:
bootm start args
bootm prep(disable interrupts, stop usb, disable caches)
bootm load_os (decompress OS image)
bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd
prep, board setup?? [or do via fdt boardsetup command])
bootm load_initrd
bootm jump
bootm restore (undo anything prep did, reset state tracking)
And we keep state around so the next stage can run w/o a lot of
arguments and you have to execute these in order, and only once. But
you can intermix other commands between the stages.
We could also have some bootm query foo to expose the internal
state if that's useful. We could completely get rid of the various
env vars that impact bootm and just make them state variables
(verify, autostart, bootm_size, bootm_low, ...)
Also, bootm would be the sequence of:
bootm start args
bootm prep
bootm load_os
bootm load_fdt
bootm load_initrd
bootm jump
comments?
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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 need is a
imload command. Thoughts on the various disable_{interrupts, usb,
caches} ?
- k
Another rough start on an outline (only cmd_bootm.c, need to add
image.c information):
http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm
Goal is to identify the major pieces of the sequence, identify what
commands we have and what we need to make a scripted equivalent
sequence for (ultimately) each path through the sequence.
I added a few bullets about functionality I'd like to see the new
sequence to be capable of it.
Thanks for updating the page.
one idea is having stages of bootm handled as sub commands:
bootm start args
bootm prep(disable interrupts, stop usb, disable caches)
bootm load_os (decompress OS image)
bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd
prep, board setup?? [or do via fdt boardsetup command])
fdt boardsetup - absolutely!
bootm load_initrd
bootm jump
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.
And we keep state around so the next stage can run w/o a lot of
arguments and you have to execute these in order, and only once. But
you can intermix other commands between the stages.
We could also have some bootm query foo to expose the internal
state if that's useful. We could completely get rid of the various
env vars that impact bootm and just make them state variables
(verify, autostart, bootm_size, bootm_low, ...)
State is bad.
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
variables: the reason we need them is because we kept throwing stuff
into bootm and then controlling it with env variables rather than
having a sequence and controlling it with what commands are in the
sequence. (Part of my simplification argument...)
Also, bootm would be the sequence of:
bootm start args
bootm prep
bootm load_os
bootm load_fdt
bootm load_initrd
bootm jump
comments?
- k
I also was thinking we should invent a new major/minor command as you
outlined, but it didn't occur to me that bootm would be a good major
command. This is a good idea: a bare bootm addr (addr|-) addr
could be used for backward compatibility and bootm subcmd for New
Improved[tm] functionality.
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
has all the capability we need (or should). The same may be also true
about load_os and load_initrd - they are copy-with-(optional)-
decompression operations (we may need additional commands for these).
Philosophy: bootm should do only bootm stuff. It (probably) should not
do any image stuff (find/copy/decompress/verify). It (probably) should
not do any fdt stuff (board fixup, other?). Etc...
Thanks,
gvb
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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 args 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 proper place, setup bootargs, initrd prep, board setup?? [or do via fdt boardsetup command]) bootm load_initrd bootm jump bootm restore (undo anything prep did, reset state tracking) 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 booting a kernel at a non-zero address. We do this on 85xx HW. Or if you are trying to boot a kernel on the second core of a dual core setup (at a non-zero address). Both of these cases we can 'bootm restore' out of. And we keep state around so the next stage can run w/o a lot of arguments and you have to execute these in order, and only once. But you can intermix other commands between the stages. Sounds like Fortran to me - let's have a big COMMON section ;-) I'm not sure if this leads to good design. I'm trying to reduce have A LOT of control logic in the script. There is a fair amount of state needed between the various stages. We could also have some bootm query foo to expose the internal state if that's useful. We could completely get rid of the various env vars that impact bootm and just make them state variables (verify, autostart, bootm_size, bootm_low, ...) I have to admit that I have no idea why bootm_size or bootm_low are needed. If we can drop these, all the better. We use them for booting at non-zero locations. verify and autostart must be kept as environment variables, because that's the way how the user can influence the boot behaviour. Even if you find a better way to implement this, they will be needed for backward compatibility. Ok. What did we decide 'autostart' means with regards to bootm? Also, bootm would be the sequence of: bootm start args bootm prep bootm load_os bootm load_fdt bootm load_initrd bootm jump I'm asking myself if that order is technically necessary. IMHO it should be possible as well to move the load_fdt step before load_os and eventually before prep, too. If you know the layout of memory than its not fully needed. The issue is knowing how big the uncompress kernel is. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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
the most complicated). One of the first things we clearly need
is a imload command. Thoughts on the various
disable_{interrupts, usb, caches} ?
- k
Another rough start on an outline (only cmd_bootm.c, need to add
image.c information):
http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm
Goal is to identify the major pieces of the sequence, identify
what commands we have and what we need to make a scripted
equivalent sequence for (ultimately) each path through the
sequence.
I added a few bullets about functionality I'd like to see the new
sequence to be capable of it.
Thanks for updating the page.
one idea is having stages of bootm handled as sub commands:
bootm start args
bootm prep(disable interrupts, stop usb, disable caches)
bootm load_os (decompress OS image)
bootm load_fdt(relocates fdt to proper place, setup bootargs,
initrd prep, board setup?? [or do via fdt boardsetup command])
fdt boardsetup - absolutely!
bootm load_initrd
bootm jump
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.
This is a buyer-beware kinda of situation. Think about a case that we
are booting a kernel at a location of memory that NO hw (usb,
interrupts, etc) would be touching. In that case you an reasonable
'bootm restore'
And we keep state around so the next stage can run w/o a lot of
arguments and you have to execute these in order, and only once.
But you can intermix other commands between the stages.
We could also have some bootm query foo to expose the internal
state if that's useful. We could completely get rid of the
various env vars that impact bootm and just make them state
variables (verify, autostart, bootm_size, bootm_low, ...)
State is bad.
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
variables: the reason we need them is because we kept throwing stuff
into bootm and then controlling it with env variables rather than
having a sequence and controlling it with what commands are in the
sequence. (Part of my simplification argument...)
Also, bootm would be the sequence of:
bootm start args
bootm prep
bootm load_os
bootm load_fdt
bootm load_initrd
bootm jump
comments?
- k
I also was thinking we should invent a new major/minor command as
you outlined, but it didn't occur to me that bootm would be a good
major command. This is a good idea: a bare bootm addr (addr|-)
addr could be used for backward compatibility and bootm
subcmd for New Improved[tm] functionality.
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 has all the capability we need (or should).
except for locating the fdt at the right location and dealing w/initrd
(but that could possibly be fixed).
The same may be also true about load_os and load_initrd - they are
copy-with-(optional)-
decompression operations (we may need additional commands for these).
Philosophy: bootm should do only bootm stuff. It (probably) should
not do any image stuff (find/copy/decompress/verify). It (probably)
should not do any fdt stuff (board fixup, other?). Etc...
This DOES NOT WORK... sorry I'm trying to make progress on this and
I'm not getting suggestions on a solutions just gripes about what I'm
suggesting.
The problem with breaking things up is that you HAVE to disable
interrupts and USB before you can reasonable load the OS image. Are
we could to add a command for each prereq. How does a user know if
they need to disable_caches on their board or not?
Also there is logic in the bootm that knows how to layout the images
based on the constraints of memory. Let use an example (assume OS
image will be loaded at 0):
bootm 100 - fff0
we load to 0, the resulting size is 1234151 bytes. So we set
filesize to 0x12D4E7. Since the fdt is in flash we have to copy it
to memory.
So what address do we copy it to? 0x12D4E7? No because we have to be
8-byte aligned. So 0x12D4F0? No because we have to ensure space for
the kernel .bss. So we have to encode all that logic in the script?
That's just asking for pain.
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications
Re: [U-Boot-Users] outline of bootm script
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 booting a kernel at a non-zero address. We do this on 85xx HW. Or if you are trying to boot a kernel on the second core of a dual core setup (at a non-zero address). Both of these cases we can 'bootm restore' out of. Agreed. But compare the benefit of such a soft recovery (versus a reset of the board) against the added complexity and irregular user interface - on this board you can write to low RAM, on the other board you crash the system; on one board the system recovers after a failed attempt to load a kernel, but maybe not always, just in certain cases, on another board it always resets the board. KISS. Define a point of no return, and after that, recovery == reset. I have to admit that I have no idea why bootm_size or bootm_low are needed. If we can drop these, all the better. We use them for booting at non-zero locations. Why is this needed? verify and autostart must be kept as environment variables, because that's the way how the user can influence the boot behaviour. Even if you find a better way to implement this, they will be needed for backward compatibility. Ok. What did we decide 'autostart' means with regards to bootm? Yes, of course we did. It means exactly what's documented in the manual. 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: [EMAIL PROTECTED] Copy from one, it's plagiarism; copy from two, it's research. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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. ack variables: the reason we need them is because we kept throwing stuff into bootm and then controlling it with env variables rather than having a sequence and controlling it with what commands are in the sequence. (Part of my simplification argument...) Hint: keep it backwards compatible, please. Yes, and then deprecate it. ;-) I also was thinking we should invent a new major/minor command as you outlined, but it didn't occur to me that bootm would be a good major command. This is a good idea: a bare bootm addr (addr|-) addr could be used for backward compatibility and bootm subcmd for New Improved[tm] functionality. How do your differentiate beween addr and subcmd then? Don't use deadbeef as a command? ;-) With judicious choices for subcmd names, we can first check for subcmd and fall through to the backward compatibility. [snip] Best regards, gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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 that NO hw (usb, interrupts, etc) would be touching. In that case you an reasonable 'bootm restore' Our exerience is that a consisten user interface and behaviour is much more important that to actually offer all options that are technically possible. For the sake of mind of a clean user interface I vote not to spend efforts on implementing such a special behaviour (which is of limited value anyway - what is the big difference between a recovery and a reset?) Philosophy: bootm should do only bootm stuff. It (probably) should not do any image stuff (find/copy/decompress/verify). It (probably) should not do any fdt stuff (board fixup, other?). Etc... This DOES NOT WORK... sorry I'm trying to make progress on this and I'm not getting suggestions on a solutions just gripes about what I'm suggesting. The problem with breaking things up is that you HAVE to disable interrupts and USB before you can reasonable load the OS image. Are we could to add a command for each prereq. How does a user know if they need to disable_caches on their board or not? 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 list of simple helper functions, or some sort of script (or list of commands stored in an environment variable) that get executed. But the developer gets the freedom to implement exactly the behaviour he wants by being able to redefine the steps he rund and their order. UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn Also there is logic in the bootm that knows how to layout the images based on the constraints of memory. Let use an example (assume OS image will be loaded at 0): bootm 100 - fff0 we load to 0, the resulting size is 1234151 bytes. So we set filesize to 0x12D4E7. Since the fdt is in flash we have to copy it to memory. 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. So what address do we copy it to? 0x12D4E7? No because we have to be 8-byte aligned. So 0x12D4F0? No because we have to ensure space for the kernel .bss. So we have to encode all that logic in the script? That's just asking for pain. Why cannot U-Boot just malloc() space for the fdt? 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: [EMAIL PROTECTED] Real programmers can write assembly code in any language. :-) - Larry Wall in [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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 has all the capability we need (or should). except for locating the fdt at the right location and dealing w/initrd (but that could possibly be fixed). The same may be also true about load_os and load_initrd - they are copy-with-(optional)- decompression operations (we may need additional commands for these). Philosophy: bootm should do only bootm stuff. It (probably) should not do any image stuff (find/copy/decompress/verify). It (probably) should not do any fdt stuff (board fixup, other?). Etc... This DOES NOT WORK... sorry I'm trying to make progress on this and I'm not getting suggestions on a solutions just gripes about what I'm suggesting. The problem with breaking things up is that you HAVE to disable interrupts and USB before you can reasonable load the OS image. Are we could to add a command for each prereq. How does a user know if they need to disable_caches on their board or not? Understood, there are some things that inherently must be done in bootm. That is why it is a philosophy and not a rule. ;-) Also there is logic in the bootm that knows how to layout the images based on the constraints of memory. Let use an example (assume OS image will be loaded at 0): bootm 100 - fff0 we load to 0, the resulting size is 1234151 bytes. So we set filesize to 0x12D4E7. Since the fdt is in flash we have to copy it to memory. So what address do we copy it to? 0x12D4E7? No because we have to be 8-byte aligned. So 0x12D4F0? No because we have to ensure space for the kernel .bss. So we have to encode all that logic in the script? That's just asking for pain. - k I agree with you, ideally the script would be just a sequence of cmd cmd cmd cmd with no conditionals other than, if a cmd failed, it aborts the sequence (I'm assuming the last cmd would be where the point of no return is embedded: copying the image over the interrupt vectors, etc.). My thoughts are that addresses would be handled by setting env variables initially and/or as a side effect of a cmd (yeah, side effects are yucky) and what is currently hard-coded as conditionals in the code would be re-scripted as /n/ scripts, where /n/ is some subset of the permutations of however many conditionals the current bootm has. We will have to see how it plays out in reality... gvb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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. Think about a case that we are booting a kernel at a location of memory that NO hw (usb, interrupts, etc) would be touching. In that case you an reasonable 'bootm restore' Our exerience is that a consisten user interface and behaviour is much more important that to actually offer all options that are technically possible. For the sake of mind of a clean user interface I vote not to spend efforts on implementing such a special behaviour (which is of limited value anyway - what is the big difference between a recovery and a reset?) Its not about recovery/reset... Philosophy: bootm should do only bootm stuff. It (probably) should not do any image stuff (find/copy/decompress/verify). It (probably) should not do any fdt stuff (board fixup, other?). Etc... This DOES NOT WORK... sorry I'm trying to make progress on this and I'm not getting suggestions on a solutions just gripes about what I'm suggesting. The problem with breaking things up is that you HAVE to disable interrupts and USB before you can reasonable load the OS image. Are we could to add a command for each prereq. How does a user know if they need to disable_caches on their board or not? 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 list of simple helper functions, or some sort of script (or list of commands stored in an environment variable) that get executed. But the developer gets the freedom to implement exactly the behaviour he wants by being able to redefine the steps he rund and their order. I understand.. but moving ALL the control logic that exists in bootm into a script language just seem like a bad idea to me. This means boots will be that much slower as we have to parse all this control logic in the shell. UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn Also there is logic in the bootm that knows how to layout the images based on the constraints of memory. Let use an example (assume OS image will be loaded at 0): bootm 100 - fff0 we load to 0, the resulting size is 1234151 bytes. So we set filesize to 0x12D4E7. Since the fdt is in flash we have to copy it to memory. 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 address the image was loaded at and the size. W/o this info I dont see how the next step can decide where to boot the .dtb or initrd. I was just 'filesize' just as part of my example. So what address do we copy it to? 0x12D4E7? No because we have to be 8-byte aligned. So 0x12D4F0? No because we have to ensure space for the kernel .bss. So we have to encode all that logic in the script? That's just asking for pain. Why cannot U-Boot just malloc() space for the fdt? Because the memory malloc() gives me isn't guaranteed to meet the set of constraints we have. (the memory can't be part of the OS image, has to be properly aligned, has to be within the BOOTMAP_SZ). - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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 list of simple helper functions, or some sort of script (or list of commands stored in an environment variable) that get executed. But the developer gets the freedom to implement exactly the behaviour he wants by being able to redefine the steps he rund and their order. I understand.. but moving ALL the control logic that exists in bootm into a script language just seem like a bad idea to me. This means boots will be that much slower as we have to parse all this control logic in the shell. If you compare the number of CPU cycles it takes to uncompress a recent kernel image against the cycles needed to parse a line of shell commands I am pretty sure that this will not actually matter. Even if it was a few milliseconds - that's something I'm more than willing to pay for the all the much cleaner code. And keep in mind that this applies only to the expert user who plays shell tricks; Johnny Luser will just run the pre-canned function builtin. 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 address the image was loaded at and the size. W/o this info I dont No, we pass the load address as argument to the loader / uncompressor. Just like we are doing it now. see how the next step can decide where to boot the .dtb or initrd. I was just 'filesize' just as part of my example. 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? Why cannot U-Boot just malloc() space for the fdt? Because the memory malloc() gives me isn't guaranteed to meet the set of constraints we have. (the memory can't be part of the OS image, has to be properly aligned, has to be within the BOOTMAP_SZ). So load it high within the limits of BOOTMAP_SZ. Please read the README again - it explains the whole philosophy as it used to be implemented 8 years ago - plain simple and reliable: load the kernel low (because that's what the kernel needed), and the ramdisk high (within the limits of RAM size and, if defined, initrd_high). If you want to stick in the DTB here, then load it before the ramdisk, and the ramdisk below it. The DTB size is easy to get, me thinks. 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: [EMAIL PROTECTED] Ever try. Ever fail. No matter. Try again. Fail again. Fail better. -- S. Beckett - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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 address the image was loaded at and the size. W/o this info I dont No, we pass the load address as argument to the loader / uncompressor. Just like we are doing it now. see how the next step can decide where to boot the .dtb or initrd. I was just 'filesize' just as part of my example. 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. Have you looked at the fdt handling code in lib_ppc/bootm.c: look at boot_get_fdt(), boot_relocate_fdt() and think about recoding that in a script. eeck! Why cannot U-Boot just malloc() space for the fdt? Because the memory malloc() gives me isn't guaranteed to meet the set of constraints we have. (the memory can't be part of the OS image, has to be properly aligned, has to be within the BOOTMAP_SZ). So load it high within the limits of BOOTMAP_SZ. Please read the README again - it explains the whole philosophy as it used to be implemented 8 years ago - plain simple and reliable: load the kernel low (because that's what the kernel needed), and the ramdisk high (within the limits of RAM size and, if defined, initrd_high). If you want to stick in the DTB here, then load it before the ramdisk, and the ramdisk below it. The DTB size is easy to get, me thinks. dtb size is NOT easy to get. It can change significantly between the raw dtb and after fdt boardsetup. - k - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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 size is NOT easy to get. It can change significantly between the raw dtb and after fdt boardsetup. I still think that it should be easy to implement a function to return the current size (plus padding, if needed). 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: [EMAIL PROTECTED] Felson's Law: To steal ideas from one person is plagiarism; to steal from many is research. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] outline of bootm script
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:
disable_interrupts /* sets an env with the state of
interrupts
before disabling */
#ifdef CONFIG_CMD_USB
disable_usb
#endif
#ifdef CONFIG_AMIGAONEG3SE
disable_caches
#endif
imload kernel_image
switch(on OS type from imload)
LINUX:
if (fdt)
fdt relocate to after kernel_image + padding
fdt fixups (board setup, etc)
if (ramdisk)
imload ramdisk
if (fdt)
fixup initrd info in fdt
bootm_linux
...
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] outline of bootm script
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, caches} ?
- k
Another rough start on an outline (only cmd_bootm.c, need to add image.c
information):
http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm
Goal is to identify the major pieces of the sequence, identify what
commands we have and what we need to make a scripted equivalent sequence
for (ultimately) each path through the sequence.
Best regards,
gvb
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
