Issue with MMU-less OMAP4

[Andrey Smirnov]

On Mon, Aug 8, 2016 at 8:10 AM, Vicenç <vicencb at gmail.com> 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