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
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
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
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 number
Peter == Peter De Schrijver pdeschrij...@nvidia.com 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
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 santosh.shilim...@ti.com
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
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 santosh.shilim...@ti.com
WBR, Sergei
--
To unsubscribe from this list: send
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 santosh.shilim...@ti.com
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
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.
-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 multiplatform
-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 it is
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 move to
-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:
Hello,
(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 have
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 how? By
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 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 of
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
-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 that maybe
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
-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 tell me
[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 effort to try
On 02/21/2013 12:15 AM, Joel A Fernandes wrote:
On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren swar...@wwwdotorg.org
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
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 it is a
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, the DT
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 swar...@wwwdotorg.org
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
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 solution that maybe
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 particular hole. Joel is
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 ideally come
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
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. bootz,
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
with its
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 zImage and DTB
Jason == Jason Gunthorpe jguntho...@obsidianresearch.com 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
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 kernel, or
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. Obviously,
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,
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
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 licenses of
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 support
Dear Nicolas,
In message alpine.lfd.2.03.1302211624561.6...@syhkavp.arg 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
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 hardware
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 for
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 (soldering
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
which don't
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 (soldering
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 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 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 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
Linaro
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 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
(call it a
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 any
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 dts files
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 to the
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
does not
On Thu, Feb 21, 2013 at 9:22 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com 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
58 matches
Mail list logo
