Re: [U-Boot] 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@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@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@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?
Regards, Simon
Thanks,
Mingkai
-----Original Message----- From: sjg@google.com [mailto:sjg@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@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@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@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
Hi Mingkai,
On Wed, Mar 6, 2013 at 2:15 AM, Hu Mingkai-B21284 B21284@freescale.com wrote:
-----Original Message----- From: sjg@google.com [mailto:sjg@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@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@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@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
participants (2)
-
Hu Mingkai-B21284 -
Simon Glass