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 platfo
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 wa
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 Monday 30 November 2015 01:0
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 Sun, 29 Nov 2015, Russe
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, Nov 28, 2015 at 12:34:23
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 wrote:
> > > > > Good. And
* 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 converging at
> > > > last
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 disag
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
> conv
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 thing
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 mi
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
7
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 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 li
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 we
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. Leavi
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 b
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 (an
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
> > r
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
> that
* 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 the atags should be
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
>
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 device driver that
>>> just loads the atags blob from /lib
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? Of course some checking
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 dy
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 dr
* 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 suggested a legacy file
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 17:10:46, Frank Rowand wrote:
>> A
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 boote
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 cou
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.
> > >
> > > I wou
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 possible to the
> > b
* 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:
> > > > > Adding devicetree list.
> > > > >
> > > >
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
> > > > http://lists.infrad
* 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
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
> > >
> > > On 1
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 October 2015 16:37:46 Pa
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 2015 13:45:09 Tony Lind
* 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:
> > > > >
> > > > > Pali, any news on posting an upd
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 the comments
> > > > addr
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 pretty much agree
> > >
* 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 really sure what to do. J
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 wrote:
> > > > > Legacy bootloaders can pa
* 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 for kernel or legacy
> > > > userspace a
* 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 for kernel or legacy
> > > userspace applications. When booting DT kernel then AT
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
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 stru
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