Matthias Fuchs wrote:
Hi Jerry,
On Monday 21 April 2008 17:16, Jerry Van Baren wrote:
Matthias Fuchs wrote:
Hi,
after going through the boom code I found out, that setting the 'autostart' variable to 'no' brings me a little closer to what I want. But finally I end up in the enable_interrupts() at the very end of do_bootm(). This freezes my system. The reason for this is the Linux kernel image that is loaded to address 0 and that overwrites the vector table. So reenabling the interrupts in U-Boot with Linux interrupt table is a bad idea.
No, having your (u-boot) interrupt go off while booting linux is a bad idea.
U-Boot calls disable_interrupt() in do_bootm(). That's fact.
Which interrupt is going off? Why is it going off (why isn't the hardware put into a quiescent state)?
So what's the best idea to fix this? I could copy the vector table onto the stack in do_bootm() and copy it back just before reenabling the interrupts.
NO NO NO.
At least this works :-)
At least once. Today. :-/
Any better idea?
Matthias
That a u-boot initialized interrupt is occurring is wrong and needs to be fixed.
- Traditionally, u-boot does not use interrupts for anything, thus this
isn't a problem.
- Proper hardware and device driver convention is that the hardware must
be quiescent when linux is started and the linux device driver must (re)configure that hardware the way it wants/needs. Obviously, this is probably a 95% rule (console I/O, memory initialization, some others may violate this rule for practical reasons).
- If your u-boot enables interrupt(s), you MUST disable the interrupt
source before starting linux. There is NO graceful way of getting linux to handle an interrupt that was a result of u-boot's running. Starting linux with interrupts disabled is not a good solution - you may get lucky but leaving an active interrupt source is a dangerous game. At best, it is a race condition that you may happen to win today.
So this means that U-Boot calling disable_interrupts before booting Linux (see do_bootm) is correct. Later my the kernel images is loaded at address 0. This overwrites all U-Boot vectors in the first 16k of RAM. So when after the kernel is loaded to address 0 and the ramdisk CRC checking failed to control is to be passed back to U-Boot it sees a mixed up vector table. I think the only ways to fix this is to save the table (as I did for testing)
That is the way of INsanity.
or check the ramdisk images before uncompressing the kernel at address 0.
That is the way of sanity.
I missed a piece of the puzzle... the problem isn't an interrupt going off in linux-land, the problem is that linux failed to run (CRC error - implies a bad load) and you are trying to recover without resetting the system.
That isn't reliable. It is possible that it could be done, but I wouldn't bet on it being reliable, at least not long term. I would anticipate that to be a very fragile solution - eventually the linux kernel will do *something* different/unexpected before aborting and your recovery mechanism will blow up.
Our current solution revolves around verifying the boot image and aborting the launch *before* attempting to launch it, before it becomes impossible to recover.
In bootm, you will see that there is a "point of no return" corresponding to replacing the interrupt vectors. After the "point of no return" we don't attempt to return from the failed bootm, but rather reset the hardware to recover. You are trying to go *way beyond* the "point of no return" (all the way to some indeterminate point in the linux boot process) and still trying to recover without a reset. Ouch. You don't know (in general) *what* the linux initialization did (it is busy scribbling on memory, if nothing else), so it is impossible to guarantee that what it did is reversible.
Except from that I just noticed that 'autostart=no' does not help me, because it completely disables booting the kernel from bootm.
So how can I achive this:
bootm $(kernel_addr_in_flash) $(randisk_addr_in_flash); run load_images_from_usb_to_ram; bootm $(kernel_addr_in_ram) $(ramdisk_addr_in_ram)
So the the initial bootm fails because of invalid images, U-Boot should load images from a USB media and start them.
The current u-boot has ways to detect invalid images before leaping. The way of sanity is to identify invalid images before leaping, and filling in holes in our detection, as necessary. The new boot image format may also be helpful here.
Matthias
Best regards, gvb