Issue with MMU-less OMAP4

Issue with MMU-less OMAP4

[Vicenç]

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.

Does that happen on other OMAP4 boards when the MMU is disabled?
Does that happen on other OMAPs?
Does that happen on other ARMs?

If a fix if found, I would be glad to test.

Thanks,
  Vicente Bergas.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Issue with MMU-less OMAP4

[Andrey Smirnov]

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Issue with MMU-less OMAP4

[Lucas Stach]

Am Montag, den 08.08.2016, 23:11 -0700 schrieb Andrey Smirnov:
> On Mon, Aug 8, 2016 at 8:10 AM, Vicenç <vicencb@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.

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

Re: Issue with MMU-less OMAP4

[Vicenç]

On Tue, Aug 9, 2016 at 10:37 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Montag, den 08.08.2016, 23:11 -0700 schrieb Andrey Smirnov:
>> On Mon, Aug 8, 2016 at 8:10 AM, Vicenç <vicencb@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.
>
> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: 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@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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox