On Mon, Jan 30, 2023 at 01:17:52PM +0100, Sascha Hauer wrote: > On Mon, Jan 30, 2023 at 09:42:53PM +1100, John Watts wrote: > > On Mon, Jan 30, 2023 at 11:27:27AM +0100, Sascha Hauer wrote: > > > This takes around 5 times too long on a i.MX8MM and around 50 times too > > > long on a i.MX6Q. This was measured under a regular barebox on the > > > shell. In an early environment with MMU disabled it takes 730 times too > > > long. > > > > Yikes! I'm glad I broke this in to its own patch then. :) > > > > I did copy this code from these boards: > > > > arch/arm/boards/cm-fx6/lowlevel.c > > arch/arm/boards/skov-imx6/lowlevel.c > > arch/arm/boards/technexion-wandboard/lowlevel.c > > arch/arm/mach-imx/xload-gpmi-nand.c > > arch/arm/mach-imx/imx6-mmdc.c (uses 1000 loops) > > > > Maybe it's time for an i.MX6-wide early udelay? > > i.MX6 is not enough, the code could run on other i.MX SoCs as well. Do you think a patch that implements udelay in PBL using the code below with a fixed base and drops these implementations would be a good idea? > I tested this with a call to this udelay function with a sufficiently > great number of microseconds surrounded by a printf. Ah okay. > I briefly looked into this, but the commit history of both barebox or > Linux do not give a real conclusion what we are waiting here for. > > Sascha I see. John.
