Hi Mingkai, On Wed, Mar 6, 2013 at 2:15 AM, Hu Mingkai-B21284 <b21...@freescale.com> wrote: > > >> -----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.
Thank you for the details explanation. I look forward to the patch. Regards, Simon > > Thanks, > Mingkai > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
