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