[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
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
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
In message 5E53E387-237D-480E-A046-68AD7F9B90A5@kernel.crashing.org 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.
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.
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.
"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.
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.
Best regards,
Wolfgang Denk
On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:
In message <5E53E387-237D-480E- A046-68AD7F9B90A5@kernel.crashing.org> 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
In message B754896C-6D4C-43B0-8F84-062884E569C2@kernel.crashing.org 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
On Aug 6, 2008, at 3:26 PM, Wolfgang Denk wrote:
In message B754896C-6D4C-43B0-8F84-062884E569C2@kernel.crashing.org 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.
Its not about recovery. Its about using the mechanism to setup the memory state to run and than using another command to jump. In a dual core setup we can run u-boot on core0 and use all the bootm commands but 'jump' to setup the state of memory. Than we can use the 'cpu' command to 'release' core1 to run that OS.
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?
We have customers that want to run at non-zero address. Think of a dual core chip with a custom OS that 0 and Linux running at 256M. (We allow this and have customers running in such situations).
"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.
ok.
- k
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
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 1000000 - fff00000
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
In message 6130E31C-5845-4DCF-A24C-4436DA575808@kernel.crashing.org 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 1000000 - fff00000
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
On Aug 6, 2008, at 3:36 PM, Wolfgang Denk wrote:
In message <6130E31C-5845-4DCF- A24C-4436DA575808@kernel.crashing.org> 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 1000000 - fff00000
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
In message 1083C28A-076D-4D63-B9B6-9FFFABFF4B54@kernel.crashing.org 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
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
In message 1C0F961D-7380-4114-8114-BD36157C2618@kernel.crashing.org 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
So I proposed something like:
bootm load_os bootm load_fdt
so I figured trying to expand on what load_os does might be useful.
input: ENV:bootm_low ENV:bootm_size BOOTMAP_SZ image specifier (a standalone uImage, a multi-uImage, a FIT specifier)
output: ERROR: if image doesn't pass validity checks ERROR: (if image is compressed) error during decompression ERROR: if resulting decompress exceeds, bootm_size/BOOTMAP_SZ ERROR: if image load address is less than bootm_low
ENV?: image OS type (LINUX, NETBSD, etc..) ENV?: LMB to keep track of memory regions used ENV?: entry point MEM: "raw memory image, decompressed, no header, etc."
I think that's everything..
So my suggestion is to keep track of the image OS type, LMB, entry point via the existing global 'static bootm_headers_t images'. If this is not acceptable it means adding support to some how pass around the LMB info via env var.
comments?
- k
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 1000000 - fff00000
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
In message 489A01A3.6000800@ge.com 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 caches, but not any interfaces.
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.
ACK.
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 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.
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?
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).
ACK.
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...
ACK.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 489A01A3.6000800@ge.com 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
participants (4)
-
Jerry Van Baren -
Jerry Van Baren -
Kumar Gala -
Wolfgang Denk