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 18:17:44 +0200 [thread overview]
Message-ID: <20160817181744.1718b747@amdc2363> (raw)
In-Reply-To: <20160817151215.GC5342@bill-the-cat>
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).
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
next prev parent reply other threads:[~2016-08-17 16:17 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 [this message]
2016-08-17 16:47 ` Tom Rini
2016-08-17 17:02 ` Lukasz Majewski
-- 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=20160817181744.1718b747@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox