On Thu, Feb 21, 2013 at 9:22 PM, Jason Gunthorpe
wrote:
> On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
>
>> The desired FPGA use case is DT updates after booting the kernel. This
>> has nothing to do with FIT images. And if the FPGA tools generate the
>> DTB, then it is certainly n
Dear Jason,
In message <20130221232821.ga2...@obsidianresearch.com> you wrote:
>
> > > own seems to be rather static and stable, and unlike software there is
> > > no way I can change it (soldering irons don't count).
> >
> > There is other hardware available (for example FPGA based) where this
On 02/21/2013 08:22 PM, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
>
>> The desired FPGA use case is DT updates after booting the kernel. This
>> has nothing to do with FIT images. And if the FPGA tools generate the
>> DTB, then it is certainly not tied t
On Thu, Feb 21, 2013 at 06:19:15PM -0600, Scott Wood wrote:
> >While embedded focused PPC stuff seems to tend to keep the kernel and
> >DT together.
>
> At least on the Freescale side of "embedded focused PPC stuff", we
> have not kept the kernel and DT together. It's actually U-Boot that
> the
On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
> The desired FPGA use case is DT updates after booting the kernel. This
> has nothing to do with FIT images. And if the FPGA tools generate the
> DTB, then it is certainly not tied to the kernel.
Completely unrelated, but do you have a
On Fri, Feb 22, 2013 at 12:27:18AM +, Russell King - ARM Linux wrote:
> > Actually we do this on PPC, the boot kernel image runs on three
> > similar hardware platforms, the image has three DTBs built into it and
> > the right one is selected at runtime. The kernel boot image does this
> > (ca
And I'm just about to set my mailer up to automatically drop the uboot
mailing list from future replies.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote:
> On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
> > Where were such guidance given?
>
> IIRC, it's been discussed a number of times on the Linux ARM kernel
> mailing list and at the various ARM workshops at kernel summit and/or
> Linar
On Thu, Feb 21, 2013 at 04:45:37PM -0700, Stephen Warren wrote:
> Well they ship x86 CPU firmware updates according to the boot log on one
> of my systems at least...
Correction: CPU microcode updates. That's updating the microcode in the
CPU which runs the x86 instruction set. It's done to fix
On Thu, Feb 21, 2013 at 04:11:06PM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
> > No it is not. FIT is about bundling a multi-platform kernel with a
> > bunch of DTBs together in a single file. I don't think you need that
> > for your embedded
On 02/21/2013 05:11:06 PM, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
> No it is not. FIT is about bundling a multi-platform kernel with a
> bunch of DTBs together in a single file. I don't think you need
that
> for your embedded system. The "wrong
On 02/21/2013 05:28 PM, Jason Gunthorpe wrote:
> On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote:
>
>>> The DT is meant to describe hardware. As far as I know, the hardware I
>>> own seems to be rather static and stable, and unlike software there is
>>> no way I can change it (sol
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Stephen Warren wrote:
>
>> On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
>>> DT installation must be outside of the distribution's responsibilities.
>>> It should be the OEM's responsibility, just like BIOS updates for PCs
>>> w
On 02/21/2013 04:11 PM, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
...
>> The DT is meant to describe hardware. As far as I know, the hardware I
>> own seems to be rather static and stable, and unlike software there is
>> no way I can change it (solde
On 02/21/2013 03:05 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
...
>> Distros already ship huge kernels with modules for every hardware out
>> there. Shipping all the DTs as well doesn't seem like a problem.
>
> But it is! Even shipping multiple kernels _is_ a problem
On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote:
> > The DT is meant to describe hardware. As far as I know, the hardware I
> > own seems to be rather static and stable, and unlike software there is
> > no way I can change it (soldering irons don't count).
>
> There is other hard
Dear Nicolas,
In message you wrote:
>
> No it is not. FIT is about bundling a multi-platform kernel with a
> bunch of DTBs together in a single file. I don't think you need that
Actually this is neither the only, nor even the primary purpose of FIT
images; these have a much wider scope of u
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
>
> > On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
> > > For embedded appliance product you may do as you wish. Nobody will
> > > interfere in the way you develop and su
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
> > For embedded appliance product you may do as you wish. Nobody will
> > interfere in the way you develop and support your own products (as long
> > as you honor the applicable license
Hi Alan,
On Feb 21, 2013, at 1:25 PM, delicious quinoa wrote:
> I like where this is heading. I'm interested in a use case where IP
> can be loaded into a FPGA, then add a blob to the device tree and load
> some drivers.
>
> I see your github tree. If I wanted to cherry-pick your code and play
I like where this is heading. I'm interested in a use case where IP
can be loaded into a FPGA, then add a blob to the device tree and load
some drivers.
I see your github tree. If I wanted to cherry-pick your code and play
around with it, which branch should I use? not-capebus-21?
Thanks,
Alan
On Thu, 21 Feb 2013, Stephen Warren wrote:
> On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
> > DT installation must be outside of the distribution's responsibilities.
> > It should be the OEM's responsibility, just like BIOS updates for PCs
> > which don't come from Fedora/Debian/Ubuntu. Obviou
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
>
> > On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
> >
> > > So let's stop kidding ourselves and be coherent please: either we move
> > > device specifics away from the
> "Jason" == Jason Gunthorpe writes:
Hi,
Jason> We've been using DT on production embedded stuff sice about 2.6.20ish
Jason> on PPC and now ARM. We treat the dtb as a kernel version specific
Jason> file, much like an initrd and ensure that the kernel only ever boots
Jason> with its prope
Dear Stephen,
In message <51267e0a.3060...@wwwdotorg.org> you wrote:
>
> > so. Just consider the typical "diskless" system that boots over the
> > network, using DHCP + TFTP, where the server will provide a single
> > file only.
>
> I use TFTP routinely to boot my boards, and load separate zImag
On Thu, Feb 21, 2013 at 07:08:20PM +, Russell King - ARM Linux wrote:
> > We've been using DT on production embedded stuff sice about 2.6.20ish
> > on PPC and now ARM. We treat the dtb as a kernel version specific
> > file, much like an initrd and ensure that the kernel only ever boots
> > wit
On 02/21/2013 12:57 PM, Wolfgang Denk wrote:
> Dear Stephen,
>
> In message <5126778a.4040...@wwwdotorg.org> you wrote:
>>
>> If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
>> just executed that, and there was a standard boot.scr that worked on all
>> boards by use of e.g.
Dear Stephen,
In message <5126778a.4040...@wwwdotorg.org> you wrote:
>
> If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
> just executed that, and there was a standard boot.scr that worked on all
> boards by use of e.g. bootz, ${soc}, ${board}, then that could be
> distro-a
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
>
> > So let's stop kidding ourselves and be coherent please: either we move
> > device specifics away from the kernel, or we keep them together. In
> > other words, the DT should ideal
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Tom Rini wrote:
>
>> On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
>>> On Thu, 21 Feb 2013, Tom Rini wrote:
>> [snip]
> uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particu
On Thu, 21 Feb 2013, Tom Rini wrote:
> On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
> > On Thu, 21 Feb 2013, Tom Rini wrote:
> [snip]
> >>> uboot dug _itself_ into this hole. It's uboot's problem.
> >>
> >> A whole lot of people dug this particular hole. Joel is trying
> >> to offer up a solut
On 02/21/2013 01:58 PM, Stephen Warren wrote:
> On 02/21/2013 12:15 AM, Joel A Fernandes wrote:
>> On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren
>> wrote:
>>> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello,
I've been spinning some work-in-progress patches for FIT build support
On Thu, Feb 21, 2013 at 11:27:24AM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
>
> > So let's stop kidding ourselves and be coherent please: either we move
> > device specifics away from the kernel, or we keep them together. In
> > other words,
On 02/21/2013 06:29 AM, Tom Rini wrote:
> On 02/20/2013 11:26 PM, Stephen Warren wrote:
>> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
>>> Hello, I've been spinning some work-in-progress patches for
>>> FIT build support in the kernel. With the move to
>>> multiplatform support on OMAP, I feel
On 02/21/2013 12:15 AM, Joel A Fernandes wrote:
> On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren
> wrote:
>> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
>>> Hello,
>>> I've been spinning some work-in-progress patches for FIT build support
>>> in the kernel.
>>> With the move to multiplatfor
[uboot list deleted again]
On Thu, Feb 21, 2013 at 06:37:07PM +0100, Wolfgang Denk wrote:
> Dear Russell,
>
> In message <20130221134656.gc17...@n2100.arm.linux.org.uk> you wrote:
> >
> > > Note that FIT images are relatively old (docs date back to March
> > > 2008). This is more of another effo
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Mark Jackson
> Sent: Thursday, February 21, 2013 10:06 PM
> To: linux-omap@vger.kernel.org
> Subject: AM335x mpurate + bogomips
>
> Before I dig any deeper, can anyone te
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
> So let's stop kidding ourselves and be coherent please: either we move
> device specifics away from the kernel, or we keep them together. In
> other words, the DT should ideally come preinstalled with the bootloader
> on a given
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
>>> uboot dug _itself_ into this hole. It's uboot's problem.
>>
>> A whole lot of people dug this particular hole. Joel is trying
>> to offer up a solution t
Dear Russell,
In message <20130221134656.gc17...@n2100.arm.linux.org.uk> you wrote:
>
> > Note that FIT images are relatively old (docs date back to March
> > 2008). This is more of another effort to try and update what the
> > kernel uses.
>
> So it's five years old and people haven't been that
On Thu, 21 Feb 2013, Tom Rini wrote:
> FIT isn't required. FIT is just trying to offer a nice usability
> thing to folks.
Usability is often counter-balanced by maintenance costs.
> A point of device trees is a single image works in a
> lot of places. FIT gives you a single file works in a lot
Before I dig any deeper, can anyone tell me if the bootarg "mpurate" is meant to
be supported for AM335x SoCs ?
I've tried it on our custom board using 3v8, but no joy.
The boot log shows:-
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-03059-g621553c-dirty (
On 02/21/2013 09:37 AM, Russell King - ARM Linux wrote:
> (Dropped uboot mailing list because it constantly holds my mails for
> moderation.)
>
> On Thu, Feb 21, 2013 at 09:08:58AM -0500, Tom Rini wrote:
>> On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote:
>>> We're about to make it harder h
(Dropped uboot mailing list because it constantly holds my mails for
moderation.)
On Thu, Feb 21, 2013 at 09:08:58AM -0500, Tom Rini wrote:
> On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote:
> > We're about to make it harder how? By forcing them to use DT
> > blobs? Or by forcing them to h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote:
> On Thu, Feb 21, 2013 at 08:20:56AM -0500, Tom Rini wrote:
>> On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
>>> On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes
>>> wrote:
>>>
On Thu, Feb 21, 2013 at 08:20:56AM -0500, Tom Rini wrote:
> On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
> > On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
> >> Hello, I've been spinning some work-in-progress patches for FIT
> >> build support in the kernel. With the m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2013 11:26 PM, Stephen Warren wrote:
> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
>> Hello, I've been spinning some work-in-progress patches for FIT
>> build support in the kernel. With the move to multiplatform
>> support on OMAP, I feel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
> On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
>> Hello, I've been spinning some work-in-progress patches for FIT
>> build support in the kernel. With the move to multiplatfor
On Thursday 21 February 2013 06:25 PM, Sergei Shtylyov wrote:
Hello.
On 20-02-2013 19:18, Santosh Shilimkar wrote:
The smp_wmb() here is out of placed
s/placed/place/
and redundant. So remove it. It is
a left over of the pain_release
Sure it's not 'pen_release'?
cleanup mostly.
On Thursday 21 February 2013 06:22 PM, Sergei Shtylyov wrote:
Hello.
On 20-02-2013 19:27, Santosh Shilimkar wrote:
OMAP5 clockdata has different sys clock clock node name. Fix the timer
code
One "clock" too many. :-)
Indeed. Will fix that.
Regards
Santosh
--
To unsubscribe from this
Hello.
On 20-02-2013 19:18, Santosh Shilimkar wrote:
The smp_wmb() here is out of placed
s/placed/place/
and redundant. So remove it. It is
a left over of the pain_release
Sure it's not 'pen_release'?
cleanup mostly.
Signed-off-by: Santosh Shilimkar
WBR, Sergei
--
To unsubsc
Hello.
On 20-02-2013 19:27, Santosh Shilimkar wrote:
OMAP5 clockdata has different sys clock clock node name. Fix the timer code
One "clock" too many. :-)
to take care of it.
Signed-off-by: Santosh Shilimkar
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe
Hello.
On 20-02-2013 19:27, Santosh Shilimkar wrote:
Allow prm init to success on OMAP5 SOCs.
s/succees/succeed/
Signed-off-by: Santosh Shilimkar
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
> "Peter" == Peter De Schrijver writes:
>>
>> Also, IMHO reset should always be done during probe() so driver can be
>> dead sure that we're starting from a known state. This is even more
Peter> Depends on the IP block. Eg: you might want to keep the screen
Peter> showing the contents
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
> Hello,
> I've been spinning some work-in-progress patches for FIT build support
> in the kernel.
> With the move to multiplatform support on OMAP, I feel it is a good
> time to add FIT support, also looking at the proliferating nu
>
> Also, IMHO reset should always be done during probe() so driver can be
> dead sure that we're starting from a known state. This is even more
Depends on the IP block. Eg: you might want to keep the screen showing the
contents drawn by the bootloader while booting the kernel and smoothly
change
Hi,
My colleagues (hardware guys) have made some EMC tests and there is some
increased emission when there is a static picture on the screen (different
than some animation takes place). They asked me to check if there
is a possibility to make such test which can help to determine the source of
t
I keep getting this BUG() when there's IPV6 traffic in in my lan on a panda
board
with these configs:
-start from a vanilla omap config
(make ARCH=arm omap2plus_defconfig)
-enable IPV6 and PREEMPT_VOLUNTARY
-turn off
CONFIG_DEBUG_SPINLOCK
CONFIG_DEBUG_MUTEXES
CONFIG_DEBUG_LOCK_ALLOC
CONFIG_PRO
58 matches
Mail list logo
