public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: socfpga: Fix cache configuration
Date: Wed, 9 Dec 2015 15:12:29 +0100	[thread overview]
Message-ID: <201512091512.29667.marex@denx.de> (raw)
In-Reply-To: <1449668929.2573.3.camel@altera.com>

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.

  reply	other threads:[~2015-12-09 14:12 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
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 [this message]
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=201512091512.29667.marex@denx.de \
    --to=marex@denx.de \
    --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