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
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&#
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
> &g
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
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
On Tue, 8 Nov 2011, Jason wrote:
> It sounds like you are intending for distributions to provide uImages.
> Why can't they provide a generic zImage, and a post-install hook runs
> mkimage to add the board specific uImage header? Similar to update-grub
> on x86{_64}. This seems _more_ flexible to
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
> >
> > > In both cases the _kernel_ image is not position independent. It must
> > > be loaded to a specific address and started at a specific entry point.
> > >
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> In message you wrote:
> >
> > > I understand you are referring here to zImages only. Correct?
> >
> > Correct. Anything else is not relocatable.
> >
> > > Or will raw images (without the preloader) be fully relocatable, too?
> >
> > No.
>
> OK. So t
On Mon, 7 Nov 2011, Simon Glass wrote:
> On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre wrote:
>
> > On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> >
> >> Dear Nicolas Pitre,
> >>
> >> > We don't want any hardcoded architecture specific address
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <4eb87375.1040...@nvidia.com> you wrote:
> >
> > The only place that has full knowledge of the board's memory layout is
> > the U-Boot environment for that board, and hence I assert that the
> > U-Boot environment shou
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
> >
> > > 1) zImages are are relocatable. They should be loaded and started at
> > >offsets between 32 KiB and 128 MiB in system RAM.
> > >
> > &g
On Mon, 7 Nov 2011, Wolfgang Denk wrote:
> Dear Marek Vasut,
>
> In message <20072204.41980.marek.va...@gmail.com> you wrote:
> >
> > You have that runtime patching stuff in linux-arm-kernel now, there should
> > be no
> > problem with that anymore actually. So basically I understood there
On Mon, 7 Nov 2011, Stephen Warren wrote:
> (Sigh, resending again to avoid rejected MIME encoding)
>
> On 11/07/2011 01:26 PM, Wolfgang Denk wrote:
> > Dear Stephen Warren,
> >
> > In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com>
> > you wrote:
> >> Anyway, I have wi
On Thu, 22 Sep 2011, Russell King - ARM Linux wrote:
> On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> > Currently uImages have the load address hardcoded. As we now try to support
> > as many ARM platforms as possible with a single binary, this becomes a
> > problem. On tegr
On Mon, 13 Sep 2010, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
> >
> > > So your problem could be solved if we were able to specify a relative
> > > load address (relative to the start of system RAM), and relative
> > &
On Mon, 13 Sep 2010, Wolfgang Denk wrote:
> Dear Nicolas,
>
> In message you wrote:
> >
> > > Maybe this should/could be addressed on the Linux side then? We don't
> > > have such problems on PwerPC, for example.
> >
> > On the Linux side, we currently have a fully position independent
> > zI
On Sun, 12 Sep 2010, Wolfgang Denk wrote:
> In message <20100912150749.gb23...@bee.dooz.org> you wrote:
> > > I don't see why uImages differ across boards - if the same kernel
> > > image can be used (i. e. the same zImage file use to generate the
> > > uImages) on these boards?
> >
> > Well, it
On Sat, 27 Jun 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 00:50 Wed 24 Jun , Prafulla Wadaskar wrote:
> > On kirkwood by default USB PHY is disabled
> > and from Linux-2.6.29 onward, phy_version for kirkwood platforms
> > are programmed to EHCI_PHY_NA, expecting such platform specific
18 matches
Mail list logo
