Issue with MMU-less OMAP4

[Sascha Hauer]

On Tue, Aug 09, 2016 at 10:37:05AM +0200, Lucas Stach wrote:
> Am Montag, den 08.08.2016, 23:11 -0700 schrieb 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?
> 
> 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.

It's probably more a sidetrack than really the wrong track. See
f98e20c582edae2713049e771f56e5e3e2ff4e31. The OMAP4 USB mode indeed uses
interrupts, so modifying the vectors won't work, even if we could change
VBAR.

> 
> 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.

Ok, can we find out if the current processor supports the V7 security
extension?

Hm, we use set_vbar() also when the MMU is enabled. Does that mean that
currently barebox on OMAP4 is generally broken?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |