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

Hu Mingkai-B21284 B21284 at freescale.com
Wed Mar 6 11:15:19 CET 2013



> -----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.

Thanks,
Mingkai



More information about the U-Boot mailing list