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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot