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? Assuming that I am right in my hypothesis, here's how I'd answer your questions: > Does that happen on other OMAP4 boards when the MMU is disabled? I would expect it to be the case, as long as you are using OMAP4 and USBBOOT the issue should manifest itself. > Does that happen on other OMAPs? I have no experience working with OMAPs, so I don't know for sure, but it should affect any similar use-case > Does that happen on other ARMs? Can't say for all of them, but on i.MX6, which I was using when creating that patch, this was not the case. Hope this helps. Thanks, Andrey _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
