> -----Original Message----- > From: s...@google.com [mailto:s...@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 <b21...@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 <s...@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 s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot