* Issue with MMU-less OMAP4 @ 2016-08-08 15:10 Vicenç 2016-08-09 6:11 ` Andrey Smirnov 0 siblings, 1 reply; 5+ messages in thread From: Vicenç @ 2016-08-08 15:10 UTC (permalink / raw) To: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issue with MMU-less OMAP4 2016-08-08 15:10 Issue with MMU-less OMAP4 Vicenç @ 2016-08-09 6:11 ` Andrey Smirnov 2016-08-09 8:37 ` Lucas Stach 0 siblings, 1 reply; 5+ messages in thread From: Andrey Smirnov @ 2016-08-09 6:11 UTC (permalink / raw) To: Vicenç; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issue with MMU-less OMAP4 2016-08-09 6:11 ` Andrey Smirnov @ 2016-08-09 8:37 ` Lucas Stach 2016-08-09 10:26 ` Vicenç 2016-08-15 9:09 ` Sascha Hauer 0 siblings, 2 replies; 5+ messages in thread From: Lucas Stach @ 2016-08-09 8:37 UTC (permalink / raw) To: Andrey Smirnov; +Cc: barebox, Vicenç 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issue with MMU-less OMAP4 2016-08-09 8:37 ` Lucas Stach @ 2016-08-09 10:26 ` Vicenç 2016-08-15 9:09 ` Sascha Hauer 1 sibling, 0 replies; 5+ messages in thread From: Vicenç @ 2016-08-09 10:26 UTC (permalink / raw) To: Lucas Stach; +Cc: Andrey Smirnov, barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Issue with MMU-less OMAP4 2016-08-09 8:37 ` Lucas Stach 2016-08-09 10:26 ` Vicenç @ 2016-08-15 9:09 ` Sascha Hauer 1 sibling, 0 replies; 5+ messages in thread From: Sascha Hauer @ 2016-08-15 9:09 UTC (permalink / raw) To: Lucas Stach; +Cc: Andrey Smirnov, barebox, Vicenç 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-08-15 9:09 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-08 15:10 Issue with MMU-less OMAP4 Vicenç 2016-08-09 6:11 ` Andrey Smirnov 2016-08-09 8:37 ` Lucas Stach 2016-08-09 10:26 ` Vicenç 2016-08-15 9:09 ` Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox