Hi,
On 15.12.2015 14:20, Russell King - ARM Linux wrote:
You could also just save_atags() in there, with a comment saying that
this is a work-around for N900 which needs the ATAGs saved, and this
is allowed in ->reserve as a special exception.
What about this (just to confirm I got the idea
On Tue, 15 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote:
> > So am I understand correctly that solution would be to hack
> > arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?
>
> That's completely unnecessary: there are enough
On Monday 30 November 2015 11:09:42 Nicolas Pitre wrote:
> On Mon, 30 Nov 2015, Pali Rohár wrote:
>
> > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > > * Pali Rohár [151129 16:16]:
> > > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > > On
On Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote:
> So am I understand correctly that solution would be to hack
> arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?
That's completely unnecessary: there are enough platform hooks to cope
with whatever the platform requires.
If you
On Tuesday 15 December 2015 10:33:25 Pali Rohár wrote:
> On Monday 30 November 2015 11:09:42 Nicolas Pitre wrote:
> > On Mon, 30 Nov 2015, Pali Rohár wrote:
> > > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > > > * Pali Rohár [151129 16:16]:
> > > > > On
On Mon, 30 Nov 2015, Pali Rohár wrote:
> On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > * Pali Rohár [151129 16:16]:
> > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > > > On Sat,
* Pali Rohár [151129 16:16]:
> On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > > Good. And Arnd likes the idea too. So we might be
On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> * Pali Rohár [151129 16:16]:
> > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre
On Sunday 29 November 2015 19:09:39 Russell King - ARM Linux wrote:
> On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > Good. And Arnd likes the idea too. So we might be converging at
> > last which is a good thing.
>
> I disagree with the idea that there is convergence. There
On Sun, Nov 29, 2015 at 07:19:18PM +0100, Pali Rohár wrote:
> On Sunday 29 November 2015 19:09:39 Russell King - ARM Linux wrote:
> > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > Good. And Arnd likes the idea too. So we might be converging at
> > > last which is a good
On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> Good. And Arnd likes the idea too. So we might be converging at last
> which is a good thing.
I disagree with the idea that there is convergence. There might be
convergence towards an idea, but... Here's a mail extract, from July
On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > Good. And Arnd likes the idea too. So we might be converging at last
> > which is a good thing.
>
> I disagree with the idea that there is convergence. There might be
>
On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > Good. And Arnd likes the idea too. So we might be converging at
> > > last which is a good thing.
> >
> > I
On Fri, Nov 27, 2015 at 06:28:50PM -0500, Nicolas Pitre wrote:
> On Fri, 27 Nov 2015, Arnd Bergmann wrote:
>
> > I don't mind creating the /proc/atags compatibility hack from the kernel
> > for a DT based N700 kernel, as long as we limit it as much as we can
> > to the machines that need it.
On Sat, Nov 28, 2015 at 01:27:07PM +0100, Arnd Bergmann wrote:
> On Friday 27 November 2015 18:28:50 Nicolas Pitre wrote:
> > On Fri, 27 Nov 2015, Arnd Bergmann wrote:
> >
> > > I don't mind creating the /proc/atags compatibility hack from the kernel
> > > for a DT based N700 kernel, as long as
On Friday 27 November 2015 18:28:50 Nicolas Pitre wrote:
> On Fri, 27 Nov 2015, Arnd Bergmann wrote:
>
> > I don't mind creating the /proc/atags compatibility hack from the kernel
> > for a DT based N700 kernel, as long as we limit it as much as we can
> > to the machines that need it. Leaving a
On Sat, 28 Nov 2015, Russell King - ARM Linux wrote:
> On Fri, Nov 27, 2015 at 06:28:50PM -0500, Nicolas Pitre wrote:
> > On Fri, 27 Nov 2015, Arnd Bergmann wrote:
> >
> > > I don't mind creating the /proc/atags compatibility hack from the kernel
> > > for a DT based N700 kernel, as long as we
On 11/28/2015 9:34 AM, Nicolas Pitre wrote:
> On Sat, 28 Nov 2015, Russell King - ARM Linux wrote:
>
>> On Fri, Nov 27, 2015 at 06:28:50PM -0500, Nicolas Pitre wrote:
>>> On Fri, 27 Nov 2015, Arnd Bergmann wrote:
>>>
I don't mind creating the /proc/atags compatibility hack from the kernel
On Fri, Nov 27, 2015 at 01:27:23PM +, Russell King - ARM Linux wrote:
> It is possible to redirect any program to open any other file. You can
> do it via a LD preload, and intercepting the open(), and possibly the
> read() calls if you want to do something more fancy. The down-side is
>
* Pali Rohár [151127 00:39]:
> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
> > Just to explore options.. How about make a minimal device driver that
> > just loads the atags blob from /lib/firmware and then shows it in
> > /proc/atags? Of course some checking
On Thu, Nov 26, 2015 at 10:07:39AM +0100, Pali Rohár wrote:
> On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote:
> > > Or populate /proc/atags only for the ones that need it from machine
> > > specific init_early?
> >
> > This is circling back to the first comment from Russell King where
On Friday 27 November 2015 19:51:48 Russell King - ARM Linux wrote:
> On Fri, Nov 27, 2015 at 01:27:23PM +, Russell King - ARM Linux wrote:
> > It is possible to redirect any program to open any other file. You can
> > do it via a LD preload, and intercepting the open(), and possibly the
> >
On Fri, 27 Nov 2015, Arnd Bergmann wrote:
> I don't mind creating the /proc/atags compatibility hack from the kernel
> for a DT based N700 kernel, as long as we limit it as much as we can
> to the machines that need it. Leaving a board file for the N700 in place
> that contains the procfs code
Hi
On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár wrote:
> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
>> Just to explore options.. How about make a minimal device driver that
>> just loads the atags blob from /lib/firmware and then shows it in
>> /proc/atags?
On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
> Just to explore options.. How about make a minimal device driver that
> just loads the atags blob from /lib/firmware and then shows it in
> /proc/atags? Of course some checking on the atags should be done by
> the driver..
And who can
Hi
On Fri, Nov 27, 2015 at 9:44 AM, Michael Trimarchi
wrote:
> Hi
>
> On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár wrote:
>> On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote:
>>> Just to explore options.. How about make a minimal
* Pali Rohár [151126 01:08]:
> On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote:
> > > Or populate /proc/atags only for the ones that need it from machine
> > > specific init_early?
> >
> > This is circling back to the first comment from Russell King where
> > he
On 26.11.2015 22:39, Tony Lindgren wrote:
Just to explore options.. How about make a minimal device driver that
just loads the atags blob from /lib/firmware and then shows it in
/proc/atags? Of course some checking on the atags should be done by
the driver..
What is the chance for such a
On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote:
> > Or populate /proc/atags only for the ones that need it from machine
> > specific init_early?
>
> This is circling back to the first comment from Russell King where
> he suggested a legacy file for the N900 which calls save_atags():
>
On 11/25/2015 1:03 PM, Tony Lindgren wrote:
> * Arnd Bergmann [151125 11:50]:
>> On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
>>> * Pali Rohár [151123 06:46]:
On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> On Wed 2015-11-11
* Pali Rohár [151123 06:46]:
> On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> > On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> > > Adding devicetree list.
> > >
> > > Thread starts at
> > >
On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> * Pali Rohár [151123 06:46]:
> > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> > > > Adding devicetree list.
> > > >
> > > > Thread starts at
> >
On Wednesday 25 November 2015 22:29:53 Arnd Bergmann wrote:
> On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote:
> > * Arnd Bergmann [151125 11:50]:
> > > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > > > At least I don't have better solutions in mind.
>
On Wednesday 25 November 2015 22:51:00 Arnd Bergmann wrote:
> On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote:
> > Arnd, my question about proper solution reminds... Proprietary
> > bootloader which cannot be replaced (e.g. it is signed or do
> > unknown magic) provides information to
On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote:
>
> Arnd, my question about proper solution reminds... Proprietary
> bootloader which cannot be replaced (e.g. it is signed or do unknown
> magic) provides information to booted kernel via custom specific ATAGs
> fields. How userspace
On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote:
> * Arnd Bergmann [151125 11:50]:
> > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > > At least I don't have better solutions in mind.
> >
> > I would be happier if we could restrict this as much as
* Arnd Bergmann [151125 11:50]:
> On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > * Pali Rohár [151123 06:46]:
> > > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> > > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> > > > >
On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> > Adding devicetree list.
> >
> > Thread starts at
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
> >
> > On 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > >
On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> Adding devicetree list.
>
> Thread starts at
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
>
> On 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > * Pali Rohár [151105 03:41]:
> >> On Tuesday 13
Adding devicetree list.
Thread starts at
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
On 11/5/2015 8:17 AM, Tony Lindgren wrote:
> * Pali Rohár [151105 03:41]:
>> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote:
>>> On Monday 12 October
On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote:
> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
> > * Pali Rohár [151012 13:29]:
> > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > > >
> > > > Pali, any news on posting an updated series with
* Pali Rohár [151105 03:41]:
> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote:
> > On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
> > > * Pali Rohár [151012 13:29]:
> > > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > > >
On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
> * Pali Rohár [151012 13:29]:
> > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > >
> > > Pali, any news on posting an updated series with the comments
> > > addressed in this thread? It seems that we all
* Tony Lindgren [150713 06:21]:
> * Pali Rohár [150707 05:00]:
> > On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote:
> > > On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote:
> > > > Legacy bootloaders can pass additional information
On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> * Tony Lindgren [150713 06:21]:
> > * Pali Rohár [150707 05:00]:
> > > On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote:
> > > > On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár
* Pali Rohár [151012 13:29]:
> On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> >
> > Pali, any news on posting an updated series with the comments
> > addressed in this thread? It seems that we all pretty much agree
> > what needs to be done.
>
> Tony, I'm not
* Pali Rohár pali.ro...@gmail.com [150707 05:00]:
On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote:
On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote:
Legacy bootloaders can pass additional information for kernel or legacy
userspace applications. When booting DT
On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote:
On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote:
Legacy bootloaders can pass additional information for kernel or legacy
userspace applications. When booting DT kernel then ATAGs structure is not
more visible after
On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote:
Legacy bootloaders can pass additional information for kernel or legacy
userspace applications. When booting DT kernel then ATAGs structure is not
more visible after running kernel uncompress code. This patch stores full
ATAGs
Legacy bootloaders can pass additional information for kernel or legacy
userspace applications. When booting DT kernel then ATAGs structure is not
more visible after running kernel uncompress code. This patch stores full
ATAGs structure into DT /chosen/linux,atags entry, so kernel can later
reuse
50 matches
Mail list logo