On Tue, Aug 9, 2016 at 10:37 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > Am Montag, den 08.08.2016, 23:11 -0700 schrieb Andrey Smirnov: >> On Mon, Aug 8, 2016 at 8:10 AM, Vicenç <vicencb@xxxxxxxxx> wrote: >> > Hello, >> > I've updated the barebox version running on an archosG9 board since a >> > long time ago and it broke. >> > After searching for the problem found the commit causing the issue: >> > http://git.pengutronix.de/?p=barebox.git;a=commitdiff;h=dba6b4919e5b678b3b78b828b54504913577d337 >> > When booting from USB is desired in an OMAP4 system, the MMU needs to >> > be disabled because the ROM code that deals with the USB >> > communications does not get on well with it. >> > >> > The issue is that it "hangs" when calling: >> > set_vbar((unsigned int)vectors); >> > I have no idea on how to fix the issue other than reverting the commit. >> > >> >> I don't have extensive knowledge of OMAP4 since I never worked with >> that SoC. However from tidbits of information that I am gleaning from >> comments in Barebox it seems that particular version of functionality >> makes use of interrupts. This gives me a strong suspicion that what >> happens is that as soon as set_vbar() call is done (which will >> re-point CPU to a different interrupt vector table) one of the >> interrupts arrives and sends the processor into la-la land, since >> Barebox exception table doesn't have anything but basic entries. >> >> So, if my guess is correct, what was happening prior to that commit >> was that on any hardware, in MMU-less mode, Barebox would not re-point >> the CPU to it's own exception handles and as such would not handle >> them at all(incorrect behavior), however that was a desired behavior >> on OMAP4 since this would result in ROM code doing all of the >> exception/interrupt handling work. And if that is the case fixing the >> problem for the rest of the SoCs, broke it for OMAP4 which was relying >> on control being passed to ROM for interrupt handling. >> >> I guess the simplest fix for this problem would be just to do: >> >> if (IS_ENABLED(CONFIG_OMA4_USBBOOT)) >> return 0; >> >> as a first thing in nommu_v7_vectors_init. As well as maybe making >> ARM_EXCEPTION dependent on MMU || !OMAP4_USBBOOT. >> >> Sascha, any preferences/suggestions? > > I think you are on the wrong track here. The likely issue is that on > OMAP only the ROM code runs in the secure world, the bootloader is > already started as non-secure. > > The register to set the VBAR is a secure only register and will trap > with an undefined instruction exception if you try to set it from the > non-secure world. > > So the correct fix would be to check if we are running non-secure and > skipping any setup code that depends on barebox running in secure mode. > This isn't really trivial, as the register to check for the current mode > is only implemented if the processor supports the V7 security extension > and will trap otherwise. This is all from the top of my head, so please > check for yourself. > > Regards, > Lucas > The testing I have done consisted on adding "putc_ll" to print something through the serial port between lines. putc_ll only uses de serial port, not the USB communications. Just before "set_vbar", "putc_ll" worked fine, after "set_vbar" it did not. In between these two "putc_ll" no ROM code has been executed. So, I thing this would strengthen Lucas version on what is going on. Regards, Vicente. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
