Re: [U-Boot] Problem with attaching UBI partition
On 03/22/2016 02:18 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi > >>> It's I belive in socfpga_common.h and it should be migrated to >>> socfpga_*_defconfig where it makes sense. Do you want to submit >>> a patch for this ? >> >> I put it in my todo list. >> Once I will finish with u-boot bringup I will submit the patch. >> Currently I have Ethernet not working :( > > Patch was submitted: > http://lists.denx.de/pipermail/u-boot/2016-March/249392.html Thanks, next time please CC me on the patches, otherwise I might miss them. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi > > It's I belive in socfpga_common.h and it should be migrated to > > socfpga_*_defconfig where it makes sense. Do you want to submit > > a patch for this ? > > I put it in my todo list. > Once I will finish with u-boot bringup I will submit the patch. > Currently I have Ethernet not working :( Patch was submitted: http://lists.denx.de/pipermail/u-boot/2016-March/249392.html Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 03/04/2016 01:24 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Marek, Hi, >>> Currently I have Ethernet not working :( >> >> OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two. > > Yes. I didn't changed that. > It is gmac1: ethernet@ff702000. > > I already started new topic for that problem here: > http://lists.denx.de/pipermail/u-boot/2016-March/247290.html > Let's continue discussion there. :) OK Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi Marek, > > Currently I have Ethernet not working :( > > OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two. Yes. I didn't changed that. It is gmac1: ethernet@ff702000. I already started new topic for that problem here: http://lists.denx.de/pipermail/u-boot/2016-March/247290.html Let's continue discussion there. :) Best regards, Denis Bakhvalov MBB Radio Platforms, RFSW -Original Message- From: EXT Marek Vasut [mailto:ma...@denx.de] Sent: Friday, March 04, 2016 13:20 To: Bakhvalov, Denis (Nokia - PL/Wroclaw) ; EXT Jagan Teki Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Problem with attaching UBI partition On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Marek, Hi, >> It's I belive in socfpga_common.h and it should be migrated to >> socfpga_*_defconfig where it makes sense. Do you want to submit >> a patch for this ? > > I put it in my todo list. > Once I will finish with u-boot bringup I will submit the patch. > Currently I have Ethernet not working :( OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Marek, Hi, >> It's I belive in socfpga_common.h and it should be migrated to >> socfpga_*_defconfig where it makes sense. Do you want to submit >> a patch for this ? > > I put it in my todo list. > Once I will finish with u-boot bringup I will submit the patch. > Currently I have Ethernet not working :( OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi Marek, > It's I belive in socfpga_common.h and it should be migrated to > socfpga_*_defconfig where it makes sense. Do you want to submit > a patch for this ? I put it in my todo list. Once I will finish with u-boot bringup I will submit the patch. Currently I have Ethernet not working :( Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 03/03/2016 12:51 PM, Stefan Roese wrote: > Hi Chin Liang, > > On 02.03.2016 13:24, Chin Liang See wrote: >>> On 01.03.2016 14:38, Chin Liang See wrote: On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote: > On 01.03.2016 07:53, Chin Liang See wrote: >> On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: >>> On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) >>> wrote: Hello Heiko, > Which U-Boot version? Which board? This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard. > Where does this leading 0xff come from? There seems a > problem > with > your spi nor flash driver? Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted. How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot? >>> >>> I believe there is a problem with caches , which we still >>> didn't >>> identify. CCing Dinh and Chin, as they were the last ones >>> looking >>> into this problem. >>> >>> For now, try doing "dcache off" before using the QSPI NOR. >>> >> >> We managed to get it work for socfpga. One of the issue dragged >> me >> long >> is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not >> defined >> in the defconfig. Hope it helps > > This is not clear to me. You mean you were able to reproduce and > solve this cache (S-bit) related issue by disabling > CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all > SoCFPGA board in mainline. > > Could you please explain in more details what exactly you did to > solve this issue on SPI NOR? > Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined. In this case, wonder any details on the failure? Intermittent? >>> >>> I think we are talking about different things here. I'm referring >>> to Marek mentioning the cache problem (S-bit related) on current >>> SoCFPGA U-Boot mainline. With caches enabled you can experience >>> problems on QSPI and on USB (reported from Marek - I didn't test >>> USB yet). >>> >> >> For QSPI, wonder the issue is on the read or write? > > I'm not 100% sure here if this never happens on read. But it definitely > happens on write. saveeenv to SPI NOR causes serious problems here > for example. > >>> So do you have any updated on this cache / S-bit problem? >> >> I am still debugging this as I notice the hub is not able to detect the >> mass storage. This is only for certain pen drive. >> >>> Or can you >>> use QSPI NOR without any issues on current mainline U-Boot with >>> caches enabled on your platforms? >>> >> >> The issue I have is on USB only. For NOR, I can ubifsmount and >> ubifsload with Micron NOR flash without issue. This is with dcache >> enabled > > Strange. I have Micron here on the SR1500 as well: > > => sf probe > SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB > > Thanks, > Stefan > The testcase is that you write some 8 MiB or so of data into the SPI NOR. Upon read-back, you will notice that the last two or so bytes of some sectors were not written completely and are corrupted. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi Chin Liang, On 02.03.2016 13:24, Chin Liang See wrote: >> On 01.03.2016 14:38, Chin Liang See wrote: >>> On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote: On 01.03.2016 07:53, Chin Liang See wrote: > On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: >> On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) >> wrote: >>> Hello Heiko, >>> Which U-Boot version? Which board? >>> >>> This is U-Boot v2016.03-rc1. I have custom board with >>> socfpga >>> Arria5 >>> onboard. >>> Where does this leading 0xff come from? There seems a problem with your spi nor flash driver? >>> >>> Yes, you're right. I have problems with the driver. As I >>> mentioned >>> in >>> previous mail when I read the contents from the flash some >>> data >>> is >>> corrupted. >>> >>> How to find out if the problem is because U-Boot has no >>> support >>> for >>> my flash (Spansion S25FL512S NOR flash with SPI) or I have >>> not >>> proper >>> configured SPI in U-Boot? >> >> I believe there is a problem with caches , which we still >> didn't >> identify. CCing Dinh and Chin, as they were the last ones >> looking >> into this problem. >> >> For now, try doing "dcache off" before using the QSPI NOR. >> > > We managed to get it work for socfpga. One of the issue dragged > me > long > is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not > defined > in the defconfig. Hope it helps This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline. Could you please explain in more details what exactly you did to solve this issue on SPI NOR? >>> >>> Nope, I am not replicating the issue. My board is having Micron >>> instead >>> of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS >>> is >>> defined in socfpga as most serial NOR flash are supporting 4k sub >>> sector. With that, it would be good to ensure the 4K is undefined. >>> >>> In this case, wonder any details on the failure? Intermittent? >> >> I think we are talking about different things here. I'm referring >> to Marek mentioning the cache problem (S-bit related) on current >> SoCFPGA U-Boot mainline. With caches enabled you can experience >> problems on QSPI and on USB (reported from Marek - I didn't test >> USB yet). >> > > For QSPI, wonder the issue is on the read or write? I'm not 100% sure here if this never happens on read. But it definitely happens on write. saveeenv to SPI NOR causes serious problems here for example. >> So do you have any updated on this cache / S-bit problem? > > I am still debugging this as I notice the hub is not able to detect the > mass storage. This is only for certain pen drive. > >> Or can you >> use QSPI NOR without any issues on current mainline U-Boot with >> caches enabled on your platforms? >> > > The issue I have is on USB only. For NOR, I can ubifsmount and > ubifsload with Micron NOR flash without issue. This is with dcache > enabled Strange. I have Micron here on the SR1500 as well: => sf probe SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On Tue, 2016-03-01 at 16:35 +0100, Stefan Roese wrote: > Hi! Hi Stefan, > > (adding Marek to Cc again) > > On 01.03.2016 14:38, Chin Liang See wrote: > > On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote: > > > On 01.03.2016 07:53, Chin Liang See wrote: > > > > On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: > > > > > On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) > > > > > wrote: > > > > > > Hello Heiko, > > > > > > > > > > > > > Which U-Boot version? Which board? > > > > > > > > > > > > This is U-Boot v2016.03-rc1. I have custom board with > > > > > > socfpga > > > > > > Arria5 > > > > > > onboard. > > > > > > > > > > > > > Where does this leading 0xff come from? There seems a > > > > > > > problem > > > > > > > with > > > > > > > your spi nor flash driver? > > > > > > > > > > > > Yes, you're right. I have problems with the driver. As I > > > > > > mentioned > > > > > > in > > > > > > previous mail when I read the contents from the flash some > > > > > > data > > > > > > is > > > > > > corrupted. > > > > > > > > > > > > How to find out if the problem is because U-Boot has no > > > > > > support > > > > > > for > > > > > > my flash (Spansion S25FL512S NOR flash with SPI) or I have > > > > > > not > > > > > > proper > > > > > > configured SPI in U-Boot? > > > > > > > > > > I believe there is a problem with caches , which we still > > > > > didn't > > > > > identify. CCing Dinh and Chin, as they were the last ones > > > > > looking > > > > > into this problem. > > > > > > > > > > For now, try doing "dcache off" before using the QSPI NOR. > > > > > > > > > > > > > We managed to get it work for socfpga. One of the issue dragged > > > > me > > > > long > > > > is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not > > > > defined > > > > in the defconfig. Hope it helps > > > > > > This is not clear to me. You mean you were able to reproduce and > > > solve this cache (S-bit) related issue by disabling > > > CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all > > > SoCFPGA board in mainline. > > > > > > Could you please explain in more details what exactly you did to > > > solve this issue on SPI NOR? > > > > > > > Nope, I am not replicating the issue. My board is having Micron > > instead > > of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS > > is > > defined in socfpga as most serial NOR flash are supporting 4k sub > > sector. With that, it would be good to ensure the 4K is undefined. > > > > In this case, wonder any details on the failure? Intermittent? > > I think we are talking about different things here. I'm referring > to Marek mentioning the cache problem (S-bit related) on current > SoCFPGA U-Boot mainline. With caches enabled you can experience > problems on QSPI and on USB (reported from Marek - I didn't test > USB yet). > For QSPI, wonder the issue is on the read or write? > So do you have any updated on this cache / S-bit problem? I am still debugging this as I notice the hub is not able to detect the mass storage. This is only for certain pen drive. > Or can you > use QSPI NOR without any issues on current mainline U-Boot with > caches enabled on your platforms? > The issue I have is on USB only. For NOR, I can ubifsmount and ubifsload with Micron NOR flash without issue. This is with dcache enabled Thanks Chin Liang > Thanks, > Stefan > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi Denis, On 1 March 2016 at 18:34, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Marek, > >>Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-) > > That solved my issue. > Thank you very much. > I removed workaround from the code. Sorry, I couldn't understand the issue nor what you solved? because, socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled and even sf probe looks no warning for enabling the same. If you haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give warning while doing 'sf probe' + SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB this will show something like SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi! (adding Marek to Cc again) On 01.03.2016 14:38, Chin Liang See wrote: On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote: On 01.03.2016 07:53, Chin Liang See wrote: On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: Hello Heiko, Which U-Boot version? Which board? This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard. Where does this leading 0xff come from? There seems a problem with your spi nor flash driver? Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted. How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot? I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem. For now, try doing "dcache off" before using the QSPI NOR. We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline. Could you please explain in more details what exactly you did to solve this issue on SPI NOR? Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined. In this case, wonder any details on the failure? Intermittent? I think we are talking about different things here. I'm referring to Marek mentioning the cache problem (S-bit related) on current SoCFPGA U-Boot mainline. With caches enabled you can experience problems on QSPI and on USB (reported from Marek - I didn't test USB yet). So do you have any updated on this cache / S-bit problem? Or can you use QSPI NOR without any issues on current mainline U-Boot with caches enabled on your platforms? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 03/01/2016 02:53 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Jagan, > >> Sorry, I couldn't understand the issue nor what you solved? because, >> socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled >> and even sf probe looks no warning for enabling the same. If you >> haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give >> warning while doing 'sf probe' > > I can see that for 2016.03-rc1 CONFIG_SPI_FLASH_BAR is not present in > socfpga_arria5_defconfig. > > Best regards, > Denis Bakhvalov > It's I belive in socfpga_common.h and it should be migrated to socfpga_*_defconfig where it makes sense. Do you want to submit a patch for this ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 03/01/2016 02:04 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Marek, > >> Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-) > > That solved my issue. > Thank you very much. > I removed workaround from the code. > > Best regards, > Denis Bakhvalov > Yay :-) -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi Jagan, > Sorry, I couldn't understand the issue nor what you solved? because, > socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled > and even sf probe looks no warning for enabling the same. If you > haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give > warning while doing 'sf probe' I can see that for 2016.03-rc1 CONFIG_SPI_FLASH_BAR is not present in socfpga_arria5_defconfig. Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote: > On 01.03.2016 07:53, Chin Liang See wrote: > > On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: > > > On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) > > > wrote: > > > > Hello Heiko, > > > > > > > > > Which U-Boot version? Which board? > > > > > > > > This is U-Boot v2016.03-rc1. I have custom board with socfpga > > > > Arria5 > > > > onboard. > > > > > > > > > Where does this leading 0xff come from? There seems a problem > > > > > with > > > > > your spi nor flash driver? > > > > > > > > Yes, you're right. I have problems with the driver. As I > > > > mentioned > > > > in > > > > previous mail when I read the contents from the flash some data > > > > is > > > > corrupted. > > > > > > > > How to find out if the problem is because U-Boot has no support > > > > for > > > > my flash (Spansion S25FL512S NOR flash with SPI) or I have not > > > > proper > > > > configured SPI in U-Boot? > > > > > > I believe there is a problem with caches , which we still didn't > > > identify. CCing Dinh and Chin, as they were the last ones looking > > > into this problem. > > > > > > For now, try doing "dcache off" before using the QSPI NOR. > > > > > > > We managed to get it work for socfpga. One of the issue dragged me > > long > > is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not > > defined > > in the defconfig. Hope it helps > > This is not clear to me. You mean you were able to reproduce and > solve this cache (S-bit) related issue by disabling > CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all > SoCFPGA board in mainline. > > Could you please explain in more details what exactly you did to > solve this issue on SPI NOR? > Nope, I am not replicating the issue. My board is having Micron instead of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is defined in socfpga as most serial NOR flash are supporting 4k sub sector. With that, it would be good to ensure the 4K is undefined. In this case, wonder any details on the failure? Intermittent? Thanks Chin Liang > Thanks, > Stefan > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi Marek, >Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-) That solved my issue. Thank you very much. I removed workaround from the code. Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 01.03.2016 07:53, Chin Liang See wrote: On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: Hello Heiko, Which U-Boot version? Which board? This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard. Where does this leading 0xff come from? There seems a problem with your spi nor flash driver? Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted. How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot? I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem. For now, try doing "dcache off" before using the QSPI NOR. We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps This is not clear to me. You mean you were able to reproduce and solve this cache (S-bit) related issue by disabling CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all SoCFPGA board in mainline. Could you please explain in more details what exactly you did to solve this issue on SPI NOR? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote: > On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > > Hello Heiko, > > > > > Which U-Boot version? Which board? > > > > This is U-Boot v2016.03-rc1. I have custom board with socfpga > > Arria5 > > onboard. > > > > > Where does this leading 0xff come from? There seems a problem > > > with > > > your spi nor flash driver? > > > > Yes, you're right. I have problems with the driver. As I mentioned > > in > > previous mail when I read the contents from the flash some data is > > corrupted. > > > > How to find out if the problem is because U-Boot has no support for > > my flash (Spansion S25FL512S NOR flash with SPI) or I have not > > proper > > configured SPI in U-Boot? > > I believe there is a problem with caches , which we still didn't > identify. CCing Dinh and Chin, as they were the last ones looking > into this problem. > > For now, try doing "dcache off" before using the QSPI NOR. > We managed to get it work for socfpga. One of the issue dragged me long is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined in the defconfig. Hope it helps Thanks Chin Liang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hello Heiko, > >> Which U-Boot version? Which board? > > This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 > onboard. > >> Where does this leading 0xff come from? There seems a problem with >> your spi nor flash driver? > > Yes, you're right. I have problems with the driver. As I mentioned in > previous mail when I read the contents from the flash some data is > corrupted. > > How to find out if the problem is because U-Boot has no support for > my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper > configured SPI in U-Boot? I believe there is a problem with caches , which we still didn't identify. CCing Dinh and Chin, as they were the last ones looking into this problem. For now, try doing "dcache off" before using the QSPI NOR. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
On 02/29/2016 05:44 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Jagan, Heiko, > >> Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase >> S25FL512S is already been added u-boot. Pls- check the same and let me >> know if you find any issues while detecting the flash. > >> Whether the driver detecting flash or not with RDID, please define >> DEBUG on drivers/mtd/spi/spi_flash.c > > I had no problems with detecting the flash. It was detected like this: > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, > total 64 MiB > > Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in > configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board). > > Actually, today I solved the problem, although in not very clean way, I think. > > As I mentioned in previous mail I had problems with reading from the flash. > Some bytes were read incorrectly. > I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version > there were no such issue. > I found out that there was some workaround introduced in order to fix this. > > So, I just apply some part of that workaround to mainline U-Boot and now it > works. > > Here is the problem in more detail: > > On previous version (2013): > U-BOOT # sf read 0x1B00 0x0380 4 > cadence_qspi_apb_indirect_read_setup. addr_value = 0x380 > cadence_qspi_apb_indirect_read_setup. rd_reg = 0x80b > cadence_qspi_apb_indirect_read_setup. device size = 0x101003 > > U-BOOT # md 0x1B00 1 > 1b00: 55424923 > > But on mainline U-Boot(2016.03-rc1) I had: > U-BOOT # sf read 0x1B00 0x0380 4 > cadence_qspi_apb_indirect_read_setup. addr_value = 0x80 > cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b > cadence_qspi_apb_indirect_read_setup. device size = 0x101002 > > U-BOOT # md 0x1B00 1 > 1b00: 554249ff > > You can see the difference in the register values that were written in QSPI > registers. > In case with mainline U-Boot I had address value not properly set. > > Here is the workaround that I've made: > > Index: drivers/mtd/spi/spi_flash.c > === > --- drivers/mtd/spi/spi_flash.c (revision 608) > +++ drivers/mtd/spi/spi_flash.c (revision 609) > @@ -29,6 +29,17 @@ > cmd[3] = addr >> 0; > } > > +#ifdef CONFIG_DBRRH_WORKAROUND > +static void spi_flash_addr32(u32 addr, u8 *cmd) > +{ > + /* cmd[0] is actual command */ > + cmd[1] = (addr >> 24) & 0xFF; > + cmd[2] = (addr >> 16) & 0xFF; > + cmd[3] = (addr >> 8) & 0xFF; > + cmd[4] = (addr >> 0) & 0xFF; > +} > +#endif > + > static int read_sr(struct spi_flash *flash, u8 *rs) > { > int ret; > @@ -510,8 +521,14 @@ > else > read_len = remain_len; > > +#ifdef CONFIG_DBRRH_WORKAROUND > + spi_flash_addr32(read_addr, cmd); > +#else > spi_flash_addr(read_addr, cmd); > +#endif > > ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len); > if (ret < 0) { > debug("SF: read failed\n"); > > Index: drivers/spi/cadence_qspi_apb.c > === > --- drivers/spi/cadence_qspi_apb.c(revision 608) > +++ drivers/spi/cadence_qspi_apb.c(revision 609) > @@ -30,6 +30,10 @@ > #include > #include "cadence_qspi.h" > > +#ifdef CONFIG_DBRRH_WORKAROUND > + #define CMD_OPTION_DUMMY_CYCLES 0x7F/* Dummy Cycles for > Read Command */ > +#endif > + > @@ -706,9 +710,25 @@ > #endif > > /* Get address */ > +#ifdef CONFIG_DBRRH_WORKAROUND > + addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], 4); > +#else > addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes); > +#endif > > +#ifdef CONFIG_DBRRH_WORKAROUND > + /* Setting Dummy Clock Cycle */ > + dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES); > + if (dummy_clk) > + { > + rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) > + << CQSPI_REG_RD_INSTR_DUMMY_LSB; > + } > +#else > + > /* The remaining lenght is dummy bytes. */ > dummy_bytes = cmdlen - addr_bytes - 1; > if (dummy_bytes) { > @@ -731,7 +751,9 @@ > rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) > << CQSPI_REG_RD_INSTR_DUMMY_LSB; > } > +#endif > > > With this correction I can read contents of the flash properly. > However, I'm a bit surprised that I was forced to make such correction like > storing 4 bytes of address (see spi_flash_addr32() above). > On the other hand I haven't found any switch that could be turned on to fix > my problem in a clean and nice way. > > With 24 bytes we can address only 16 MB. How cadence driver is supposed to > work for larger spaces? > Is this 4th byte comes from somewhere else? > > Jagan, Hei
Re: [U-Boot] Problem with attaching UBI partition
+ Marek On 29 February 2016 at 22:14, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Jagan, Heiko, > >> Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase >> S25FL512S is already been added u-boot. Pls- check the same and let me >> know if you find any issues while detecting the flash. > >> Whether the driver detecting flash or not with RDID, please define >> DEBUG on drivers/mtd/spi/spi_flash.c > > I had no problems with detecting the flash. It was detected like this: > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, > total 64 MiB So, the flash size is > 32MiB means, your config enabled BAR(Bank address register) which means accessing flash more than 16MiB using 3-byte addressing support. > > Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in > configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board). > > Actually, today I solved the problem, although in not very clean way, I think. > > As I mentioned in previous mail I had problems with reading from the flash. > Some bytes were read incorrectly. > I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version > there were no such issue. > I found out that there was some workaround introduced in order to fix this. > > So, I just apply some part of that workaround to mainline U-Boot and now it > works. > > Here is the problem in more detail: > > On previous version (2013): > U-BOOT # sf read 0x1B00 0x0380 4 > cadence_qspi_apb_indirect_read_setup. addr_value = 0x380 > cadence_qspi_apb_indirect_read_setup. rd_reg = 0x80b > cadence_qspi_apb_indirect_read_setup. device size = 0x101003 > > U-BOOT # md 0x1B00 1 > 1b00: 55424923 > > But on mainline U-Boot(2016.03-rc1) I had: > U-BOOT # sf read 0x1B00 0x0380 4 > cadence_qspi_apb_indirect_read_setup. addr_value = 0x80 > cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b > cadence_qspi_apb_indirect_read_setup. device size = 0x101002 > > U-BOOT # md 0x1B00 1 > 1b00: 554249ff > > You can see the difference in the register values that were written in QSPI > registers. > In case with mainline U-Boot I had address value not properly set. > > Here is the workaround that I've made: > > Index: drivers/mtd/spi/spi_flash.c > === > --- drivers/mtd/spi/spi_flash.c (revision 608) > +++ drivers/mtd/spi/spi_flash.c (revision 609) > @@ -29,6 +29,17 @@ > cmd[3] = addr >> 0; > } > > +#ifdef CONFIG_DBRRH_WORKAROUND > +static void spi_flash_addr32(u32 addr, u8 *cmd) > +{ > + /* cmd[0] is actual command */ > + cmd[1] = (addr >> 24) & 0xFF; > + cmd[2] = (addr >> 16) & 0xFF; > + cmd[3] = (addr >> 8) & 0xFF; > + cmd[4] = (addr >> 0) & 0xFF; > +} > +#endif > + > static int read_sr(struct spi_flash *flash, u8 *rs) > { > int ret; > @@ -510,8 +521,14 @@ > else > read_len = remain_len; > > +#ifdef CONFIG_DBRRH_WORKAROUND > + spi_flash_addr32(read_addr, cmd); > +#else > spi_flash_addr(read_addr, cmd); > +#endif > > ret = spi_flash_read_common(flash, cmd, cmdsz, data, > read_len); > if (ret < 0) { > debug("SF: read failed\n"); > > Index: drivers/spi/cadence_qspi_apb.c > === > --- drivers/spi/cadence_qspi_apb.c (revision 608) > +++ drivers/spi/cadence_qspi_apb.c (revision 609) > @@ -30,6 +30,10 @@ > #include > #include "cadence_qspi.h" > > +#ifdef CONFIG_DBRRH_WORKAROUND > + #define CMD_OPTION_DUMMY_CYCLES 0x7F/* Dummy Cycles for > Read Command */ > +#endif > + > @@ -706,9 +710,25 @@ > #endif > > /* Get address */ > +#ifdef CONFIG_DBRRH_WORKAROUND > + addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], 4); > +#else > addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes); > +#endif > > +#ifdef CONFIG_DBRRH_WORKAROUND > + /* Setting Dummy Clock Cycle */ > + dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES); > + if (dummy_clk) > + { > + rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) > + << CQSPI_REG_RD_INSTR_DUMMY_LSB; > + } > +#else > + > /* The remaining lenght is dummy bytes. */ > dummy_bytes = cmdlen - addr_bytes - 1; > if (dummy_bytes) { > @@ -731,7 +751,9 @@ > rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) > << CQSPI_REG_RD_INSTR_DUMMY_LSB; > } > +#endif > > > With this correction I can read contents of the flash properly. > However, I'm a bit surprised that I was forced to make such correction like > storing 4 bytes of address (see spi_flash_addr32() above). Instead of 4-byte addressing, u-boot using only 3-byte addressing with BAR support for accessing flash's more
Re: [U-Boot] Problem with attaching UBI partition
Hi Jagan, Heiko, > Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase > S25FL512S is already been added u-boot. Pls- check the same and let me > know if you find any issues while detecting the flash. > Whether the driver detecting flash or not with RDID, please define > DEBUG on drivers/mtd/spi/spi_flash.c I had no problems with detecting the flash. It was detected like this: SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 64 MiB Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board). Actually, today I solved the problem, although in not very clean way, I think. As I mentioned in previous mail I had problems with reading from the flash. Some bytes were read incorrectly. I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version there were no such issue. I found out that there was some workaround introduced in order to fix this. So, I just apply some part of that workaround to mainline U-Boot and now it works. Here is the problem in more detail: On previous version (2013): U-BOOT # sf read 0x1B00 0x0380 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x380 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x80b cadence_qspi_apb_indirect_read_setup. device size = 0x101003 U-BOOT # md 0x1B00 1 1b00: 55424923 But on mainline U-Boot(2016.03-rc1) I had: U-BOOT # sf read 0x1B00 0x0380 4 cadence_qspi_apb_indirect_read_setup. addr_value = 0x80 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b cadence_qspi_apb_indirect_read_setup. device size = 0x101002 U-BOOT # md 0x1B00 1 1b00: 554249ff You can see the difference in the register values that were written in QSPI registers. In case with mainline U-Boot I had address value not properly set. Here is the workaround that I've made: Index: drivers/mtd/spi/spi_flash.c === --- drivers/mtd/spi/spi_flash.c (revision 608) +++ drivers/mtd/spi/spi_flash.c (revision 609) @@ -29,6 +29,17 @@ cmd[3] = addr >> 0; } +#ifdef CONFIG_DBRRH_WORKAROUND +static void spi_flash_addr32(u32 addr, u8 *cmd) +{ + /* cmd[0] is actual command */ + cmd[1] = (addr >> 24) & 0xFF; + cmd[2] = (addr >> 16) & 0xFF; + cmd[3] = (addr >> 8) & 0xFF; + cmd[4] = (addr >> 0) & 0xFF; +} +#endif + static int read_sr(struct spi_flash *flash, u8 *rs) { int ret; @@ -510,8 +521,14 @@ else read_len = remain_len; +#ifdef CONFIG_DBRRH_WORKAROUND + spi_flash_addr32(read_addr, cmd); +#else spi_flash_addr(read_addr, cmd); +#endif ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len); if (ret < 0) { debug("SF: read failed\n"); Index: drivers/spi/cadence_qspi_apb.c === --- drivers/spi/cadence_qspi_apb.c (revision 608) +++ drivers/spi/cadence_qspi_apb.c (revision 609) @@ -30,6 +30,10 @@ #include #include "cadence_qspi.h" +#ifdef CONFIG_DBRRH_WORKAROUND + #define CMD_OPTION_DUMMY_CYCLES 0x7F/* Dummy Cycles for Read Command */ +#endif + @@ -706,9 +710,25 @@ #endif /* Get address */ +#ifdef CONFIG_DBRRH_WORKAROUND + addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], 4); +#else addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes); +#endif +#ifdef CONFIG_DBRRH_WORKAROUND + /* Setting Dummy Clock Cycle */ + dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES); + if (dummy_clk) + { + rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) + << CQSPI_REG_RD_INSTR_DUMMY_LSB; + } +#else + /* The remaining lenght is dummy bytes. */ dummy_bytes = cmdlen - addr_bytes - 1; if (dummy_bytes) { @@ -731,7 +751,9 @@ rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK) << CQSPI_REG_RD_INSTR_DUMMY_LSB; } +#endif With this correction I can read contents of the flash properly. However, I'm a bit surprised that I was forced to make such correction like storing 4 bytes of address (see spi_flash_addr32() above). On the other hand I haven't found any switch that could be turned on to fix my problem in a clean and nice way. With 24 bytes we can address only 16 MB. How cadence driver is supposed to work for larger spaces? Is this 4th byte comes from somewhere else? Jagan, Heiko, please evaluate my correction. Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hi Denis, On 24 February 2016 at 14:29, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hello Heiko, > >> Which U-Boot version? Which board? > > This is U-Boot v2016.03-rc1. > I have custom board with socfpga Arria5 onboard. > >> Where does this leading 0xff come from? There seems a problem >> with your spi nor flash driver? > > Yes, you're right. I have problems with the driver. > As I mentioned in previous mail when I read the contents from the flash some > data is corrupted. > > How to find out if the problem is because U-Boot has no support for my flash > (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI > in U-Boot? Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase S25FL512S is already been added u-boot. Pls- check the same and let me know if you find any issues while detecting the flash. Whether the driver detecting flash or not with RDID, please define DEBUG on drivers/mtd/spi/spi_flash.c thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hello Denis, Am 24.02.2016 um 09:59 schrieb Bakhvalov, Denis (Nokia - PL/Wroclaw): Hello Heiko, Which U-Boot version? Which board? This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard. Where does this leading 0xff come from? There seems a problem with your spi nor flash driver? Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted. How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot? Sorry, I have no such similiar HW ... You have to look into the flashs datasheet and your RM for your SoC and find out whats the problem ... added Jagan (SPI custodian) maybe he has an idea... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hello Heiko, > Which U-Boot version? Which board? This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5 onboard. > Where does this leading 0xff come from? There seems a problem > with your spi nor flash driver? Yes, you're right. I have problems with the driver. As I mentioned in previous mail when I read the contents from the flash some data is corrupted. How to find out if the problem is because U-Boot has no support for my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in U-Boot? Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with attaching UBI partition
Hello Dennis, Am 22.02.2016 um 15:17 schrieb Bakhvalov, Denis (Nokia - PL/Wroclaw): Dear U-Boot support, I have problems while running following commands in U-Boot: Which U-Boot version? Which board? U-Boot => sf probe 0 0 0 SF: Detected S25FL512S with page size 512, total: 67108864 U-Boot => mtdparts device nor0 , # parts = 4 #: namesizeoffset mask_flags 0: boot0x0010 0x 0 1: bootenv 0x0008 0x0010 0 2: SomeInfo0x0198 0x0018 0 3: ubifspart 0x0250 0x01b0 0 U-Boot => ubi part ubifspart mtd: Giving out device 1 to mtd=3 ubi0: attaching mtd1 UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48 UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20 UBI DBG gen (pid 1): min_io_size 1 UBI DBG gen (pid 1): max_write_size 512 UBI DBG gen (pid 1): hdrs_min_io_size 1 UBI DBG gen (pid 1): ec_hdr_alsize64 UBI DBG gen (pid 1): vid_hdr_alsize 64 UBI DBG gen (pid 1): vid_hdr_offset 64 UBI DBG gen (pid 1): vid_hdr_aloffset 64 UBI DBG gen (pid 1): vid_hdr_shift0 UBI DBG gen (pid 1): leb_start128 UBI DBG gen (pid 1): max_erroneous16 UBI DBG gen (pid 1): process PEB 0 UBI DBG bld (pid 1): scan PEB 0 UBI DBG io (pid 1): read EC header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:0 ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead of 55424923 Erase counter header dump: magic 0xff554249 Where does this leading 0xff come from? There seems a problem with your spi nor flash driver? I am currently on the EW 2016 in nuernberg, I could not look deeper here... I think try to check your spi nor flash driver... bye, Heiko version35 ec 0 vid_hdr_offset 16777216 data_offset1073741824 image_seq -2142856561 hdr_crc0xe046ed erase counter header hexdump: UBI DBG bld (pid 1): bad magic number at PEB 0: ff554249 instead of 55424923 UBI DBG io (pid 1): read VID header from PEB 0 UBI DBG io (pid 1): read 64 bytes from PEB 0:64 UBI DBG bld (pid 1): no VID header found at PEB 0, only 0xFF bytes UBI DBG bld (pid 1): add to erase: PEB 0, EC -1 ... // this warning goes for all PEBs from 1 to 147 ubi0: scanning is finished UBI DBG gen (pid 1): max. sequence number: 0 ubi0 error: ubi_read_volume_table: the layout volume was not found ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22 UBI error: cannot attach mtd1 UBI error: cannot initialize UBI, error -22 UBI init error 22 UBI init error 22 For me it looks like this magic number is shifted one byte right, although I can't understand why. Here is how I create UBI partition in Linux env: Linux Env #> mtdinfo -a mtd5 Name: data Type: nor Eraseblock size:262144 bytes, 256.0 KiB Amount of eraseblocks: 148 (38797312 bytes, 37.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:10 Bad blocks are allowed: false Device is writable: true Linux Env #> ubiformat /dev/mtd5 ubiformat: mtd5 (nor), size 38797312 bytes (37.0 MiB), 148 eraseblocks of 262144 bytes (256.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 147 -- 100 % complete ubiformat: 148 eraseblocks are supposedly empty ubiformat: formatting eraseblock 147 -- 100 % complete 797312 Linux Env #> ubiattach -m 5 /dev/ubi_ctrl UBI: attaching mtd5 to ubi0 UBI: scanning is finished UBI: attached mtd5 (name "part5", size 37 MiB) to ubi0 UBI: PEB size: 262144 bytes (256 KiB), LEB size: 262016 bytes UBI: min./max. I/O unit sizes: 1/256, sub-page size 1 UBI: VID header offset: 64 (aligned 64), data offset: 128 UBI: good PEBs: 148, bad PEBs: 0, corrupted PEBs: 0 UBI: user volume: 0, internal volumes: 1, max. volumes count: 128 UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 1371523162 UBI: available PEBs: 144, total reserved PEBs: 4, PEBs reserved for bad PEB handling: 0 UBI: background thread "ubi_bgt0d" started, PID 1003 Linux Env #> ubimkvol -N data -m /dev/ubi0 Linux Env #> mount -t ubifs ubi0:data /mnt Linux Env #> mount -t ubifs ubi0:data /mnt UBIFS: default file-system created UBIFS: background thread "ubifs_bgt0_0" started, PID 1010 UBIFS: mounted UBI device 0, volume 0, name "data" UBIFS: LEB size: 262016 bytes (255 KiB), min./max. I/O unit sizes: 8 bytes/256 bytes UBIFS: FS size: 35110144 bytes (33 MiB, 134 LEBs), journal size 2096129 bytes (1 MiB, 7 LEBs) UBIFS: reserved for root: 1658338 bytes (1619 KiB) UBIFS: media format: w4/r0 (latest is w4/r0), UUID 696FFD7B-1957-4ABD-9FDC-ED0EEB674D9D, small LPT model It's perfectly working from Linux env, however U-Boot don't want to attach UBI partition. Please help me identify the problem! Best regards, Denis B
Re: [U-Boot] Problem with attaching UBI partition
Hi, I found that I have problem with reading flash contents: When dumping the flash from Linux env: $ cat /dev/mtd5 > /tmp/flash.bin : 55424923 0100 0003 But when I dump the flash contents from U-Boot I see this: => sf read 0x1B00 0x01B0 0x1000 => md 0x1B00 1b00: 494255ff 0123 So, that's why I see this print: ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead of 55424923 I will investigate why data was read from flash incorrectly. Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot