Re: [U-Boot] Falcon mode boot support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
Hi Tom,
Following the experiment that yielded the following results:
U-Boot time sf read ${loadaddr} 0x20 ${loadsize}
I get the following back:
SF: 2541352 bytes @ 0x20 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
On Wed, Dec 17, 2014 at 04:27:37PM -, Andy Pont wrote:
Hi Tom,
Following the experiment that yielded the following results:
U-Boot time sf read ${loadaddr} 0x20 ${loadsize}
I get the following back:
SF: 2541352 bytes @ 0x20 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
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
Hi Tom, How big is the args file? We default to placing the args at 0x8800 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 0x8100. 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
On Tue, Dec 16, 2014 at 12:58:33PM -, Andy Pont wrote: Hi Tom, How big is the args file? We default to placing the args at 0x8800 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 0x8100. 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 signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
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} 0x20 ${loadsize}
I get the following back:
SF: 2541352 bytes @ 0x20 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 300 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Falcon mode boot support
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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
On Mon, Dec 15, 2014 at 04:20:46PM -, 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 80f8, end 80f85928
Which means the size is 0x5928.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
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 80f8, 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: 0x8100 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode boot support
On Mon, Dec 15, 2014 at 09:08:08PM -, 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 80f8, 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: 0x8100 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 0x8800 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 0x8100. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
