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 :-) > > > 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) or check the ramdisk images before uncompressing the kernel at address 0. 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. Matthias ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
