All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <l.majewski@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [GIT] Pull request: u-boot-dfu
Date: Wed, 17 Aug 2016 19:02:10 +0200	[thread overview]
Message-ID: <20160817190210.1859ef89@amdc2363> (raw)
In-Reply-To: <20160817164734.GF5342@bill-the-cat>

Hi Tom,

> On Wed, Aug 17, 2016 at 06:17:44PM +0200, Lukasz Majewski wrote:
> > Hi Tom,
> > 
> > > On Wed, Aug 17, 2016 at 04:55:52PM +0200, Lukasz Majewski wrote:
> > > > Hi Tom,
> > > > 
> > > > > On Wed, Aug 17, 2016 at 11:56:59AM +0200, Lukasz Majewski
> > > > > wrote:
> > > > > > Hi Heiko, Ravi,
> > > > > > 
> > > > > > > Hello B, Ravi,
> > > > > > > 
> > > > > > > Am 17.08.2016 um 09:40 schrieb B, Ravi:
> > > > > > > > Hi Heiko
> > > > > > > >
> > > > > > > >>>>
> > > > > > > >>>> is that for master or next ?
> > > > > > > >
> > > > > > > >>> This patch _was_ supposed to go to "master"
> > > > > > > >
> > > > > > > >>>> Was this build tested ?
> > > > > > > >
> > > > > > > >>> Unfortunately, not so thoroughly as I thought.
> > > > > > > >
> > > > > > > >>> Moving dfu code to SPL causes following error on some
> > > > > > > >>> boards:
> > > > > > > >
> > > > > > > >>>        arm:  +   smartweb
> > > > > > > >>> +In file included from ../include/dfu.h:18:0,
> > > > > > > >>> +                 from ../common/dfu.c:16:
> > > > > > > >>> +../include/linux/usb/composite.h:331:9: error:
> > > > > > > >>> requested alignment is +not an integer constant
> > > > > > > >>> +  struct usb_device_descriptor
> > > > > > > >>> __aligned(CONFIG_SYS_CACHELINE_SIZE) desc;
> > > > > > > >>> +         ^
> > > > > > > >>> +make[3]: *** [spl/common/dfu.o] Error 1
> > > > > > > >>> +make[2]: *** [spl/common] Error 2
> > > > > > > >> +make[1]: *** [spl/u-boot-spl] Error 2
> > > > > > > >>> +make: *** [sub-make] Error 2
> > > > > > > >
> > > > > > > > The CONFIG_SYS_CACHELINE_SIZE is not defined for
> > > > > > > > smartweb platform which is causing build error. By
> > > > > > > > defining this error goes away. What would be value for
> > > > > > > > cache line size for smartweb platform? (32/64/..?)
> > > > > > > 
> > > > > > > Hups? Which patch introduced this? I wonder if other at91
> > > > > > > based boards does not show the same error?
> > > > > > > 
> > > > > > > The RM for the at91sam9260 says:  8 words cache line size
> > > > > > > 
> > > > > > > So 32 would be the correct value.
> > > > > > 
> > > > > > Heiko, thanks for your support.
> > > > > > 
> > > > > > Ravi, Marek Vasut before accepting PR tests following archs
> > > > > > with buildman: arm, aarch64, mips, powerpc, nios2 [1]
> > > > > > 
> > > > > > Regarding the CONFIG_SYS_CACHELINE_SIZE, some older boards
> > > > > > do not define it. Hence we have several problems (also with
> > > > > > other patches http://patchwork.ozlabs.org/patch/657216/).
> > > > > > 
> > > > > > IMHO, it would be best to check [1] and then add this
> > > > > > define if required.
> > > > > > 
> > > > > > Or does anybody have any better idea?
> > > > > 
> > > > > This is something we can get right in Kconfig, I believe.
> > > > > Looking at the Linux Kernel, the relevant bits I think are in
> > > > > arch/arm/mm/Kconfig: config ARM_L1_CACHE_SHIFT_6
> > > > >         bool
> > > > >         default y if CPU_V7
> > > > >         help
> > > > >           Setting ARM L1 cache line size to 64 Bytes.
> > > > > 
> > > > > config ARM_L1_CACHE_SHIFT
> > > > >         int
> > > > >         default 6 if ARM_L1_CACHE_SHIFT_6
> > > > >         default 5
> > > > > 
> > > > > I only hesitate a little as there's not a 1:1 match-up between
> > > > > those values and all ARMv7 platforms we have today for
> > > > > example.
> > > > 
> > > > True.
> > > > 
> > > > I do recall that some Cortex-A9 had 32B L1 cache and Cortex-A8
> > > > had 64B L1 cache line size.
> > > > 
> > > > And both were ARMv7 cores.
> > > 
> > > I had a quick conversation with some folks and the answer is that
> > > it's OK to round up (as it appears that our uses of
> > > CONFIG_SYS_CACHELINE_SIZE are) so long as the mechanics of the
> > > flushes work at the smallest implemented increment, which is what
> > > the Linux Kernel does and we're using that code.  So we should be
> > > safe to mirror the kernel logic here.
> > 
> > +1
> > 
> > If I understood you correctly, for armv7 boards with undefined
> > CONFIG_SYS_CACHELINE_SIZE we should use the largest cache line (IIRC
> > 64B).
> 
> I'm saying we should just mirror the kernel and universally use 64B on
> CPU_V7 (and note, not V7M) and 32B otherwise, wrt ARM at least.
> 

Ok, now it is clear :-)

Thanks for providing solution.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

  reply	other threads:[~2016-08-17 17:02 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 13:41 [U-Boot] [GIT] Pull request: u-boot-dfu Lukasz Majewski
2016-08-16 13:49 ` Marek Vasut
2016-08-16 16:03   ` Lukasz Majewski
2016-08-17  7:16     ` B, Ravi
2016-08-17  7:40     ` B, Ravi
2016-08-17  7:53       ` Heiko Schocher
2016-08-17  8:41         ` B, Ravi
2016-08-17  9:56         ` Lukasz Majewski
2016-08-17 13:06           ` Tom Rini
2016-08-17 14:55             ` Lukasz Majewski
2016-08-17 15:12               ` Tom Rini
2016-08-17 16:17                 ` Lukasz Majewski
2016-08-17 16:47                   ` Tom Rini
2016-08-17 17:02                     ` Lukasz Majewski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-09-13 11:07 Łukasz Majewski
2017-09-13 12:05 ` Marek Vasut
2017-08-28 19:28 Łukasz Majewski
2017-08-28 20:32 ` Marek Vasut
2017-08-28 21:33   ` Łukasz Majewski
2017-08-28 23:26     ` Marek Vasut
2017-08-21  9:16 Łukasz Majewski
2017-08-21  9:31 ` Marek Vasut
2017-07-20 10:03 Łukasz Majewski
2017-07-20 11:07 ` Marek Vasut
2017-07-20 12:01   ` Łukasz Majewski
2017-07-20 12:05     ` Marek Vasut
2017-06-18 19:16 Lukasz Majewski
2017-06-18 19:46 ` Marek Vasut
2017-06-03 17:18 Lukasz Majewski
2017-06-03 17:26 ` Marek Vasut
2017-03-27 11:23 Lukasz Majewski
2017-03-27 11:57 ` Marek Vasut
2017-02-22 12:36 Lukasz Majewski
2017-02-26 12:22 ` Marek Vasut
2016-11-02 15:28 Lukasz Majewski
2016-11-02 19:42 ` Marek Vasut
2016-11-03  8:24   ` Lukasz Majewski
2016-11-03 10:57     ` Marek Vasut
2016-08-29 14:24 Lukasz Majewski
2016-08-29 19:25 ` Marek Vasut
2016-05-06  9:17 Lukasz Majewski
2016-05-06 16:41 ` Marek Vasut
2016-04-25 15:40 Lukasz Majewski
2016-04-25 15:57 ` Marek Vasut
2016-04-26  7:20   ` Lukasz Majewski
2016-04-22 16:33 Lukasz Majewski
2016-04-22 16:38 ` Stephen Warren
2016-04-22 16:54   ` Marek Vasut
2016-04-14 10:04 Lukasz Majewski
2016-04-14 10:08 ` Marek Vasut
2016-02-12 11:04 Lukasz Majewski
2016-02-12 12:32 ` Marek Vasut
2016-02-12 13:51   ` Lukasz Majewski
2016-02-12 16:29     ` Marek Vasut
2016-02-15  9:30       ` Lukasz Majewski
2016-02-15 13:52         ` Marek Vasut
2015-10-30 10:40 Lukasz Majewski
2015-10-31  2:12 ` Marek Vasut
2015-08-26 15:32 Lukasz Majewski
2015-08-26 16:50 ` Marek Vasut
2015-08-24 13:21 Lukasz Majewski
2015-08-24 13:34 ` Marek Vasut
2015-07-20  9:51 Lukasz Majewski
2015-07-22  6:59 ` Marek Vasut
2015-06-08 14:28 Lukasz Majewski
2015-06-08 15:31 ` Marek Vasut
2015-04-14  8:22 Lukasz Majewski
2015-04-15 13:55 ` Tom Rini
2015-02-23  9:06 Lukasz Majewski
2015-02-24 17:56 ` Marek Vasut
2015-02-24 22:29   ` Lukasz Majewski
2015-02-25 12:18     ` Marek Vasut
2015-02-25 13:09       ` Lukasz Majewski
2015-02-25 16:47         ` Marek Vasut
2014-11-14 16:54 Lukasz Majewski
2014-11-14 20:09 ` Marek Vasut
2014-09-24 12:24 Lukasz Majewski
2014-09-24 19:05 ` Marek Vasut
2014-09-25  7:35   ` Lukasz Majewski
2014-09-25  8:40     ` Marek Vasut
2014-09-02  7:13 Lukasz Majewski
2014-09-02 12:34 ` Marek Vasut
2014-07-16  7:18 Lukasz Majewski
2014-07-23 18:15 ` Marek Vasut
2014-08-06 15:54   ` Stephen Warren
2014-08-10 16:10     ` Lukasz Majewski
2014-08-10 20:40       ` Marek Vasut
2014-05-26  5:46 Lukasz Majewski
2014-06-05 21:13 ` Marek Vasut
2014-06-06  6:32   ` Lukasz Majewski
2014-06-09 10:32   ` Lukasz Majewski
2014-06-09 10:51     ` Lukasz Majewski
2014-06-09 17:32       ` Marek Vasut
2014-06-10  6:10         ` Lukasz Majewski
2014-06-10 14:08           ` Marek Vasut

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=20160817190210.1859ef89@amdc2363 \
    --to=l.majewski@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.