On Wednesday, December 09, 2015 at 02:48:49 PM, Chin Liang See wrote:
On Tue, 2015-12-08 at 13:54 +0100, Marek Vasut wrote:
On Tuesday, December 08, 2015 at 01:04:29 PM, Stefan Roese wrote:
On 08.12.2015 12:13, Pavel Machek wrote:
> > 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.
It caused regressions it was not supposed to change. That means revert...
Yes, please revert and hopefully someone will find the time to find and fix the problem with this dcache at some time.
Me, already done, see the other email ;-)
Sorry for the inconvenience. But I didn't notice any problems with it until now.
You were just lucky ;-)
With the mentioned bug, the value that will be programmed to ttbr0 is the tlb_address itself. The value I have (through bdinfo command) is 0x3fff0000. Wonder what is the value when the issue happen? Just try to understand more.
Check this patch:
[PATCH] arm: Replace test for CONFIG_ARMV7 with CONFIG_CPU_V7
Me and Albert isolated things to S bit in the page tables, which fixes things, but causes slowness on the socfpga.