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 _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
