Hi Hemut, On 31 March 2014 05:29, Helmut Raiger <helmut.rai...@hale.at> wrote:
> On 02/13/2014 10:03 AM, Helmut Raiger wrote: > >> >> >> But you just inspired me! There are probably interrupts running >> for some time when the second u-boot starts and the relocation >> might destroy part of the interrupt entry points .... >> >> Thx for asking the right questions. >> I'll have to check this. >> >> Helmut >> > > I'm finally able to start the second u-boot (other things in-between as > always). > If I do a cleanup_before_linux(), i.e. turn off interrupts and caches > before > the actual 'go' and it works just fine. > > For testing I patched the go command, but obviously this can't be > contributed as such. > > Anyone having a suggestion on how to do this? > > 1) add option to 'go' command, which is hard as it has variable arguments > 2) add another go command > 3) use an environment variable to set the option for 'go' > > Theoretically I could use a u-boot image to encapsulate the second u-boot > and use 'bootm', but I think I'll stumble over the same kind of questions. There is already 'dcache off' but I wonder if something like 'go prepare' would be useful? Another option is that bootm has a prepare state, but it requires an image. Regards, Simon > > -- > Scanned by MailScanner. > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
