Re: Issue with MMU-less OMAP4

[Vicenç <vicencb@gmail.com>]

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