[U-Boot] Hang issue when applied patch "spi: Add SPI flash test"

[Simon Glass]

Hi Mingkai,

On Wed, Mar 6, 2013 at 2:15 AM, Hu Mingkai-B21284 <B21284 at freescale.com> wrote:
>
>
>> -----Original Message-----
>> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
>> Sent: Monday, March 04, 2013 9:59 PM
>> To: Hu Mingkai-B21284
>> Cc: U-Boot Mailing List
>> Subject: Re: Hang issue when applied patch "spi: Add SPI flash test"
>>
>> +U-Boot mailing list
>>
>> Hi Mingkai,
>>
>> On Mon, Mar 4, 2013 at 12:48 AM, Hu Mingkai-B21284 <B21284 at freescale.com>
>> wrote:
>> > Hi Simon,
>> >
>> >
>> >
>> > After applied following patch, read from SPI flash will hang on
>> > p2041rdb board.
>> >
>> >
>> >
>> > From 2400727318a0a1ecf15a9deae85b0719c4c47aba Mon Sep 17 00:00:00 2001
>> >
>> > From: Simon Glass <sjg at chromium.org>
>> >
>> > Date: Mon, 8 Oct 2012 13:16:02 +0000
>> >
>> > Subject: [PATCH] spi: Add SPI flash test
>> >
>> >
>> >
>> > It is useful to have a basic SPI flash test, which tests that the SPI
>> > chip,
>> >
>> > the SPI bus and the driver are behaving.
>> >
>> >
>> >
>> > This test erases part of the flash, writes data and reads it back as a
>> >
>> > sanity check that all is well.
>> >
>> >
>> >
>> > Use CONFIG_SF_TEST to enable it.
>> >
>> >
>> >
>> > Signed-off-by: Simon Glass sjg at chromium.org
>> >
>> >
>> >
>> > If included the div64 header file after common.h, it doesn't hang
>> anymore.
>> >
>> > Do you have any suggestions?
>> >
>> >
>> >
>> > +#include <div64.h>
>> >
>> > #include <common.h>
>> >
>> >
>>
>> Well I think div64.h should be after common, so it is fine to move it.
>> I am not sure why that causes a hang though - do you have more details
>> - e.g. what did you do when it hangs, what is console output? Also do you
>> define CONFIG_CMD_SF_TEST?
>>
> I used "sf read 1000000 0 10000" command to read from SPI flash. I didn't
> Define CONFIG_CMD_SF_TEST.
>
> The header file div64.h includes <asm/types.h> which defines the phys_addr_t
> according to the macro CONFIG_PHYS_64BIT, while the macro CONFIG_PHYS_64BIT
> is included in common.h, so the phys_addr_t in file cmd_sf.c will be defined as
> "unsigned long" and will be defined as "unsigned long long" in other files
> when CONFIG_PHYS_64BIT is defined.
>
> In this case, when we pass 32bit address to map_physmem, the address will be
> put into higher 32 bit, and lower 32bit is a wild value owning to call conventions.
>
> static int do_spi_flash_read_write(int argc, char * const argv[])
> {
>         map_physmem(addr, len, MAP_WRBACK);
> }
>
> For example, when we use "sf read 0x1000000 0 1000" to read SPI flash, the address
> 0x1000000 will be passed into map_physmem, but we get address 0x1000000000000a in
> function addrmap_phys_to_virt. Obviously the value 0x1000000000000a is out of the
> range of address_map which will return memory address 0xffffffff for memory map.
>
> The interrupt vectors in U-Boot are put at address 0x100/0x200/0x300 etc, so sf read
> command will overlap the interrupt vectors which will cause unexpected behavior.
>
> I will submit a patch for this later.

Thank you for the details explanation. I look forward to the patch.

Regards,
Simon

>
> Thanks,
> Mingkai
>