[U-Boot] Falcon mode boot support

[U-Boot] Falcon mode boot support

[Tom Rini]

On Mon, Dec 15, 2014 at 04:20:46PM -0000, Andy Pont wrote:

> Hello,
> 
> I am currently setting up the Falcon mode support for a custom AM3354 based
> platform that has U-Boot and the Linux kernel in an SPI NOR flash.
> 
> Following the instructions I have loaded the kernel to ${loadaddr} and
> device tree to ${fdtaddr} from the SPI flash device and then have run:
> 
> U-Boot> spl export fdt ${loadaddr} - ${fdtaddr}
> 
> Which seems to have executed correctly as the output ends:
> 
> Argument image is now in RAM: 0x8fb3d000
> 
> I now need to save this generated data into the SPI ROM but can't figure out
> how much I need to write.  Could someone let me know how to work it out?

So first, take a look at drivers/mtd/spi/spi_spl_load.c as that's what
will be doing falcon mode work on your SPI flash.

Second, take a look at board/ti/am335x/README, you're looking for the
lines that read like:
Using Device Tree in place at 80f80000, end 80f85928

Which means the size is 0x5928.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141215/6e3d4fbe/attachment.pgp>

[U-Boot] Falcon mode boot support

[Andy Pont]

Hi Tom,

> So first, take a look at drivers/mtd/spi/spi_spl_load.c as that's what
> will be doing falcon mode work on your SPI flash.
> 
> Second, take a look at board/ti/am335x/README, you're looking for the
> lines that read like:
> Using Device Tree in place at 80f80000, end 80f85928

I have managed to make some progress and I think I have got what I think is
the right data stored in the flash.  Unfortunately when I try to boot it
locks up at:

spl: payload image: Linu load addr: 0x80007fc0 size: 3893360
Jumping to Linux
Entering kernel arg pointer: 0x80000100

I'm guessing the kernel arg pointer value is incorrect either that or it has
ignored the boot arguments and not picked up the console parameter.

Could you advise?

Thanks,

Andy.

[U-Boot] Falcon mode boot support

[Tom Rini]

On Mon, Dec 15, 2014 at 09:08:08PM -0000, Andy Pont wrote:
> Hi Tom,
> 
> > So first, take a look at drivers/mtd/spi/spi_spl_load.c as that's what
> > will be doing falcon mode work on your SPI flash.
> > 
> > Second, take a look at board/ti/am335x/README, you're looking for the
> > lines that read like:
> > Using Device Tree in place at 80f80000, end 80f85928
> 
> I have managed to make some progress and I think I have got what I think is
> the right data stored in the flash.  Unfortunately when I try to boot it
> locks up at:
> 
> spl: payload image: Linu load addr: 0x80007fc0 size: 3893360
> Jumping to Linux
> Entering kernel arg pointer: 0x80000100
> 
> I'm guessing the kernel arg pointer value is incorrect either that or it has
> ignored the boot arguments and not picked up the console parameter.
> 
> Could you advise?

How big is the args file?  We default to placing the args at 0x88000000
in ti_am335x_common.h (see CONFIG_SYS_SPL_ARGS_ADDR) to make sure that
we don't have an overlap between the DT and the kernel which is quite
possible with a reasonably sized DT and placing it at 0x80000100.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141215/7425e308/attachment.pgp>

[U-Boot] Falcon mode boot support

[Andy Pont]

Hi Tom,

> How big is the args file?  We default to placing the args at 0x88000000
> in ti_am335x_common.h (see CONFIG_SYS_SPL_ARGS_ADDR) to make sure that
> we don't have an overlap between the DT and the kernel which is quite
> possible with a reasonably sized DT and placing it at 0x80000100.

Changing the CONFIG_SYS_SPL_ARGS_ADDR to be the same as the value in the ti_
am335x_common.h header file seems to have fixed the issue.

Unfortunately it hasn't improved the boot time by much - the bulk of the
time seems to be in reading and decompressing the kernel from SPI flash
device (Spansion S25FL164).  The only other storage medium on the board is
an eMMC flash device - would putting the kernel in there give a faster boot
time?

Thanks,

Andy.

[U-Boot] Falcon mode boot support

[Tom Rini]

On Tue, Dec 16, 2014 at 12:58:33PM -0000, Andy Pont wrote:
> Hi Tom,
> 
> > How big is the args file?  We default to placing the args at 0x88000000
> > in ti_am335x_common.h (see CONFIG_SYS_SPL_ARGS_ADDR) to make sure that
> > we don't have an overlap between the DT and the kernel which is quite
> > possible with a reasonably sized DT and placing it at 0x80000100.
> 
> Changing the CONFIG_SYS_SPL_ARGS_ADDR to be the same as the value in the ti_
> am335x_common.h header file seems to have fixed the issue.
> 
> Unfortunately it hasn't improved the boot time by much - the bulk of the
> time seems to be in reading and decompressing the kernel from SPI flash
> device (Spansion S25FL164).  The only other storage medium on the board is
> an eMMC flash device - would putting the kernel in there give a faster boot
> time?

eMMC is likely to be faster, yes.  You may also want to see what can be
trimmed from the kernel binary, in either case, and if going with an
uncompressed kernel ends up being quicker.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141216/337b9efa/attachment.pgp>

[U-Boot] Falcon mode boot support

[Andy Pont]

Hi Tom,

> eMMC is likely to be faster, yes.  You may also want to see what can be
> trimmed from the kernel binary, in either case, and if going with an
> uncompressed kernel ends up being quicker.

There are I think two issues going on here one with decompression time
which, as you say, I can resolve by using an uncompressed kernel.  The other
is with the SPI transfer time and some testing has shown that if I boot to
U-Boot and then run:

U-Boot> time sf read ${loadaddr} 0x200000 ${loadsize}

I get the following back:

SF: 2541352 bytes @ 0x200000 Read: OK
time: 2.447 seconds

The Spansion datasheet states that in read mode it can transfer 6.25Mbytes/s
in standard read mode at 50MHz clock.  I have the clock at 40MHz as the
device on the other SPI interface won't support anything faster.

When I tested this on the Starter Kit reference board and again on the
target hardware I had to increase the value of SPI_WAIT_TIMEOUT in
driver/spi/omap3_spi.c from 3000000 by adding an extra '0' in order to stop
getting read failures with "sf read" commands with more than about 2MB of
data as per the discussion on the TI E2E community here:
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/366019/1293837.aspx#1293837
.

Regards,

Andy.

[U-Boot] Falcon mode boot support

[Andy Pont]

Hi Tom,

Following the experiment that yielded the following results:

> U-Boot> time sf read ${loadaddr} 0x200000 ${loadsize}
> 
> I get the following back:
> 
> SF: 2541352 bytes @ 0x200000 Read: OK
> time: 2.447 seconds

I have done some reading and poking around and have added the
OMAP3_MCSPI_CHCONF_TURBO flag to the SPI channel enablement in the
omap3_spi_read() function within omap3_spi.c and now the same command takes
1.279 seconds to execute.

I have also added a couple of printf() statements around the call to read
the flash device that loads the kernel image in spi_load_image_os() and the
timestamps on the output to the serial console consistently show that it is
taking around 3.5 seconds to load the same kernel image.

I haven't fully looked into what is going on as I haven't yet found the full
call path from spi_flash_read() in spi_flash.h to when it eventually results
in the call to omap3_spi_read() and so it may be doing more and I'm not
actually comparing apples with apples.

Could you (or maybe Jagannadha as SPI custodian) point me in the right
direction?

Thanks,

Andy.

[U-Boot] Falcon mode boot support

[Tom Rini]

On Wed, Dec 17, 2014 at 04:27:37PM -0000, Andy Pont wrote:
> Hi Tom,
> 
> Following the experiment that yielded the following results:
> 
> > U-Boot> time sf read ${loadaddr} 0x200000 ${loadsize}
> > 
> > I get the following back:
> > 
> > SF: 2541352 bytes @ 0x200000 Read: OK
> > time: 2.447 seconds
> 
> I have done some reading and poking around and have added the
> OMAP3_MCSPI_CHCONF_TURBO flag to the SPI channel enablement in the
> omap3_spi_read() function within omap3_spi.c and now the same command takes
> 1.279 seconds to execute.
> 
> I have also added a couple of printf() statements around the call to read
> the flash device that loads the kernel image in spi_load_image_os() and the
> timestamps on the output to the serial console consistently show that it is
> taking around 3.5 seconds to load the same kernel image.
> 
> I haven't fully looked into what is going on as I haven't yet found the full
> call path from spi_flash_read() in spi_flash.h to when it eventually results
> in the call to omap3_spi_read() and so it may be doing more and I'm not
> actually comparing apples with apples.
> 
> Could you (or maybe Jagannadha as SPI custodian) point me in the right
> direction?

I suspect that this might be related to the general problem on these
part families where SPL isn't as fast as we expect it to be, perhaps
cache related.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141217/8e06863d/attachment.pgp>

[U-Boot] Falcon mode boot support

[Andy Pont]

Hi Tom,

> I suspect that this might be related to the general problem on these
> part families where SPL isn't as fast as we expect it to be, perhaps
> cache related.

I did a bit of digging around following this line of thought and found an
old discussion on the mailing list
(http://lists.denx.de/pipermail/u-boot/2013-June/156949.html) regarding
someone who had a very similar problem with SPL/Falcon and NAND flash.

I have emailed Bas van den Berg to see if he is willing to share his final
implementation as adding the code that adds the SRAM to the MMU and enables
the caches to the end of am33xx_spl_board_init() hangs within the
enable_caches() function.

Unfortunately this getting well out of my comfort zone with the ARM cores
and so I'm not sure where to go next and how to debug it further.

Regards,

Andy.

[U-Boot] Falcon mode boot support

[Andy Pont]

Hello,

I am currently setting up the Falcon mode support for a custom AM3354 based
platform that has U-Boot and the Linux kernel in an SPI NOR flash.

Following the instructions I have loaded the kernel to ${loadaddr} and
device tree to ${fdtaddr} from the SPI flash device and then have run:

U-Boot> spl export fdt ${loadaddr} - ${fdtaddr}

Which seems to have executed correctly as the output ends:

Argument image is now in RAM: 0x8fb3d000

I now need to save this generated data into the SPI ROM but can't figure out
how much I need to write.  Could someone let me know how to work it out?

Thanks,

Andy.