From: Chin Liang See <clsee@altera.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration
Date: Mon, 7 Dec 2015 22:47:28 +0800 [thread overview]
Message-ID: <1449499648.2213.24.camel@altera.com> (raw)
In-Reply-To: <201512071544.15138.marex@denx.de>
On Mon, 2015-12-07 at 15:44 +0100, Marek Vasut wrote:
> On Monday, December 07, 2015 at 03:37:17 PM, Chin Liang See wrote:
> > On Thu, 2015-12-03 at 17:22 +0100, Marek Vasut wrote:
> > > On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See
> > > wrote:
> > >
> > > [...]
> > >
> > > > > I have another board where I cannot use UBI on QSPI NOR and
> > > > > reverting
> > > > > this
> > > > > patch magically fixes things.
> > > >
> > > > I was testing this too as enabling the UBIFS on NOR and here
> > > > are my
> > > > output. Wonder how to simulate your errors as I can help to
> > > > take a
> > > > look?
> > > >
> > > >
> > > > => icache
> > > > Instruction Cache is ON
> > > > => dcache
> > > > Data (writethrough) Cache is ON
> > > > => sf probe
> > > > SF: Detected N25Q512 with page size 256 Bytes, erase size 4
> > > > KiB,
> > > > total
> > > > 64 MiB
> > > > => mtdparts default
> > > > => mtdparts
> > > >
> > > > device nor0 <ff705000.spi>, # parts = 4
> > > > #: name size offset
> > > > mask_flags
> > > > 0: u-boot 0x00100000 0x00000000 0
> > > > 1: uboot-env 0x00010000 0x00100000 0
> > > > 2: rootfs 0x01000000 0x00110000 0
> > > > 3: UBI 0x02ef0000 0x01110000 0
> > > >
> > > > active partition: nor0,0 - (u-boot) 0x00100000 @ 0x00000000
> > > >
> > > > defaults:
> > > > mtdids : nor0=ff705000.spi
> > > > mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot
> > > > -env),16m(rootfs),
> > > > -(UBI)
> > > > => sf erase u-boot 100000
> > > > SF: 1048576 bytes @ 0x0 Erased: OK
> > > > => ubi part u-boot
> > > > ubi0: attaching mtd1
> > > > ubi0: scanning is finished
> > > > ubi0: empty MTD device detected
> > > > ubi0: attached mtd1 (name "mtd=0", size 1 MiB)
> > > > ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
> > > > ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
> > > > ubi0: VID header offset: 64 (aligned 64), data offset: 128
> > > > ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
> > > > ubi0: user volume: 0, internal volumes: 1, max. volumes count:
> > > > 23
> > > > ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image
> > > > sequence
> > > > number: 0
> > > > ubi0: available PEBs: 252, total reserved PEBs: 4, PEBs
> > > > reserved
> > > > for
> > > > bad PEB handling: 0
> > > > => ubi createvol testvol c0000
> > > > Creating dynamic volume testvol of size 786432
> > > > => ubi write 0 testvol 100
> > > > 256 bytes written to volume testvol
> > > > => ubi read 200 testvol 100
> > > > Read 256 bytes from volume testvol to 200
> > > > => cmp.b 0 200 100
> > > > Total of 256 byte(s) were the same
> > > > => ubifsmount testvol
> > > > Error reading superblock on volume 'testvol' errno=-22!
> > > > ubifsmount - mount UBIFS volume
> > > >
> > > > Usage:
> > > > ubifsmount <volume-name>
> > > >
> > > > - mount 'volume-name' volume
> > > >
> > > > => ubifsmount ubi0:testvol
> > > > Error reading superblock on volume 'ubi0:testvol' errno=-22!
> > > > ubifsmount - mount UBIFS volume
> > > >
> > > > Usage:
> > > > ubifsmount <volume-name>
> > > >
> > > > - mount 'volume-name' volume
> > > >
> > > > In the mean time, I was not able to get ubifsmount works.
> > > > Appreciate
> > > > for any quick advise? Else will look into the code tomorrow as
> > > > my
> > > > bed
> > > > is calling me :)
> > >
> > > I usually write ubinized image into the "rootfs" partition (sf
> > > erase
> > > and
> > > then sf write) and then do 'ubi part rootfs' , which fails with
> > > error
> > > 22
> > > unless I revert this patch. If I dump the SPI NOR area after
> > > writing
> > > the
> > > data, I see that the last 2 bytes of some pages are corrupted.
> > >
> > > I am using these parameters to generate my ~11MiB large ubinized
> > > image:
> > > MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> > > UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> > >
> > > Here is the content of my ubinize.cfg:
> > > [rootfs]
> > > mode=ubi
> > > image=root.ubifs
> > > vol_id=0
> > > vol_type=dynamic
> > > vol_name=rootfs
> > > vol_flags=autoresize
> >
> > Thanks for the pointers.
> >
> > I checked the source and enabled the debug message. Noticed my
> > failure
> > is due to small LEB and PEB size. It was set to 4k which is the sub
> > -sector erase size of NOR flash. I suspect you didn't hit this as
> > you
> > generate ubinized image which is 64kB erase size.
> >
> > I will continue to dig more. Need to ensure it works when user
> > create
> > UBI part in U-Boot on top of serial NOR flash (which is commonly
> > 4kB
> > erase size). Hopefully existing U-Boot already have source taking
> > care
> > this :)
>
> I am tempted to revert this patch, since it breaks USB and UBI for me
> on two different boards though.
I believe good to go ahead then as functionality is critical then
performance. The next patch for this would need to get your help to
test it as I have challenge to reproduce this. Need to understand the
reason through the cache drivers.
Thanks
Chin Liang
next prev parent reply other threads:[~2015-12-07 14:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 15:30 [U-Boot] [PATCH] arm: socfpga: Fix cache configuration Stefan Roese
2015-09-17 15:37 ` Marek Vasut
2015-09-18 6:16 ` Pavel Machek
2015-09-18 6:24 ` Stefan Roese
2015-09-18 6:34 ` Pavel Machek
2015-09-18 6:41 ` Stefan Roese
2015-11-09 0:10 ` Marek Vasut
2015-11-09 11:42 ` Stefan Roese
2015-11-09 13:49 ` Marek Vasut
2015-11-09 15:46 ` Stefan Roese
2015-11-09 16:02 ` Marek Vasut
2015-11-12 0:49 ` Chin Liang See
2015-11-12 0:53 ` Marek Vasut
2015-11-12 2:33 ` Chin Liang See
2015-11-12 3:48 ` Marek Vasut
2015-12-03 0:10 ` Marek Vasut
2015-12-03 16:11 ` Chin Liang See
2015-12-03 16:22 ` Marek Vasut
2015-12-07 14:37 ` Chin Liang See
2015-12-07 14:44 ` Marek Vasut
2015-12-07 14:47 ` Chin Liang See [this message]
2015-12-08 11:13 ` Pavel Machek
2015-12-08 12:04 ` Stefan Roese
2015-12-08 12:54 ` Marek Vasut
2015-12-09 13:48 ` Chin Liang See
2015-12-09 14:12 ` Marek Vasut
2015-12-08 12:53 ` Marek Vasut
2015-12-09 13:50 ` Chin Liang See
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1449499648.2213.24.camel@altera.com \
--to=clsee@altera.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox