Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1274798 > unrolled thread

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Pavel Machek <pavel@ucw.cz> - 2015-11-22 08:00 +0100
    Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Pali Rohár <pali.rohar@gmail.com> - 2015-11-23 15:50 +0100
      Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Tony Lindgren <tony@atomide.com> - 2015-11-25 19:20 +0100
        Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Arnd Bergmann <arnd@arndb.de> - 2015-11-25 20:50 +0100
          Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Tony Lindgren <tony@atomide.com> - 2015-11-25 22:10 +0100
            Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Arnd Bergmann <arnd@arndb.de> - 2015-11-25 22:40 +0100
              Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Pali Rohár <pali.rohar@gmail.com> - 2015-11-25 22:50 +0100
                Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Arnd Bergmann <arnd@arndb.de> - 2015-11-25 23:00 +0100
                  Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Pali Rohár <pali.rohar@gmail.com> - 2015-11-25 23:10 +0100
            Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags"  entry Frank Rowand <frowand.list@gmail.com> - 2015-11-26 05:30 +0100
              Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Pali Rohár <pali.rohar@gmail.com> - 2015-11-26 10:10 +0100
                Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Tony Lindgren <tony@atomide.com> - 2015-11-26 21:50 +0100
                  Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> - 2015-11-26 22:20 +0100
                  Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Pali Rohár <pali.rohar@gmail.com> - 2015-11-27 09:40 +0100
                    Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Michael Trimarchi <michael@amarulasolutions.com> - 2015-11-27 09:50 +0100
                      Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Michael Trimarchi <michael@amarulasolutions.com> - 2015-11-27 10:00 +0100
                    Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Tony Lindgren <tony@atomide.com> - 2015-11-27 16:00 +0100
                Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-27 14:30 +0100
                  Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-27 21:00 +0100
                    Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Arnd Bergmann <arnd@arndb.de> - 2015-11-27 22:10 +0100
                      Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-11-28 00:30 +0100
                        Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Arnd Bergmann <arnd@arndb.de> - 2015-11-28 13:30 +0100
                          Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-28 14:00 +0100
                        Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-28 13:40 +0100
                          Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-11-28 18:40 +0100
                            Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags"  entry Frank Rowand <frowand.list@gmail.com> - 2015-11-28 22:10 +0100
                            Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-29 19:20 +0100
                              Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Pali Rohár <pali.rohar@gmail.com> - 2015-11-29 19:20 +0100
                                Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-30 00:20 +0100
                              Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Pali Rohár <pali.rohar@gmail.com> - 2015-11-30 01:20 +0100
                              Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-11-30 01:20 +0100

Page 1 of 2  [1] 2  Next page →

#1274798 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

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 <pali.rohar@gmail.com> [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 <pali.rohar@gmail.com> [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.
> 
> I'm not real happy with the concept of patches 4 and 5 in this series.
> My concern is that those two patches are using the FDT as a transport
> mechanism for a binary blob (the atags object).

Umm. Ok. Do you have alternative proposal that works for everyone?

I mean. This discussion was going for quite a long time, and it would
be nice to have some solution... patch proposal... something.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1275458

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:
> > > * Pali Rohár <pali.rohar@gmail.com> [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 <pali.rohar@gmail.com> [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.
> > 
> > I'm not real happy with the concept of patches 4 and 5 in this series.
> > My concern is that those two patches are using the FDT as a transport
> > mechanism for a binary blob (the atags object).
> 
> Umm. Ok. Do you have alternative proposal that works for everyone?
> 
> I mean. This discussion was going for quite a long time, and it would
> be nice to have some solution... patch proposal... something.
> 									Pavel

Yes, discussion is going for a long time! So should I spend time for
adding documentation to my solution (this is last one thing which is
missing)? Or my solution is wrong and somebody else will propose new?
I do not want to spend time on something which will be rejected and
discarded.

-- 
Pali Rohár
pali.rohar@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277674

* Pali Rohár <pali.rohar@gmail.com> [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 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > > > * Pali Rohár <pali.rohar@gmail.com> [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 <pali.rohar@gmail.com> [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.
> > > 
> > > I'm not real happy with the concept of patches 4 and 5 in this series.
> > > My concern is that those two patches are using the FDT as a transport
> > > mechanism for a binary blob (the atags object).
> > 
> > Umm. Ok. Do you have alternative proposal that works for everyone?
> > 
> > I mean. This discussion was going for quite a long time, and it would
> > be nice to have some solution... patch proposal... something.
> > 									Pavel
> 
> Yes, discussion is going for a long time! So should I spend time for
> adding documentation to my solution (this is last one thing which is
> missing)? Or my solution is wrong and somebody else will propose new?
> I do not want to spend time on something which will be rejected and
> discarded.

At least I don't have better solutions in mind.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277752 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> * Pali Rohár <pali.rohar@gmail.com> [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 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > > > > * Pali Rohár <pali.rohar@gmail.com> [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 <pali.rohar@gmail.com> [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.
> > > > 
> > > > I'm not real happy with the concept of patches 4 and 5 in this series.
> > > > My concern is that those two patches are using the FDT as a transport
> > > > mechanism for a binary blob (the atags object).
> > > 
> > > Umm. Ok. Do you have alternative proposal that works for everyone?
> > > 
> > > I mean. This discussion was going for quite a long time, and it would
> > > be nice to have some solution... patch proposal... something.
> > >                                                                     Pavel
> > 
> > Yes, discussion is going for a long time! So should I spend time for
> > adding documentation to my solution (this is last one thing which is
> > missing)? Or my solution is wrong and somebody else will propose new?
> > I do not want to spend time on something which will be rejected and
> > discarded.
> 
> 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
boards that need it, as an opt-in. That way it doesn't become an ABI
for people that don't already rely in this information. How about
adding a check the code adds the linux,atags property to do it
only for a whitelist of board numbers?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277805

* Arnd Bergmann <arnd@arndb.de> [151125 11:50]:
> On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > * Pali Rohár <pali.rohar@gmail.com> [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 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > > > > > * Pali Rohár <pali.rohar@gmail.com> [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 <pali.rohar@gmail.com> [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.
> > > > > 
> > > > > I'm not real happy with the concept of patches 4 and 5 in this series.
> > > > > My concern is that those two patches are using the FDT as a transport
> > > > > mechanism for a binary blob (the atags object).
> > > > 
> > > > Umm. Ok. Do you have alternative proposal that works for everyone?
> > > > 
> > > > I mean. This discussion was going for quite a long time, and it would
> > > > be nice to have some solution... patch proposal... something.
> > > >                                                                     Pavel
> > > 
> > > Yes, discussion is going for a long time! So should I spend time for
> > > adding documentation to my solution (this is last one thing which is
> > > missing)? Or my solution is wrong and somebody else will propose new?
> > > I do not want to spend time on something which will be rejected and
> > > discarded.
> > 
> > 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
> boards that need it, as an opt-in. That way it doesn't become an ABI
> for people that don't already rely in this information. How about
> adding a check the code adds the linux,atags property to do it
> only for a whitelist of board numbers?

Or populate /proc/atags only for the ones that need it from machine
specific init_early?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277814 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [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
> > boards that need it, as an opt-in. That way it doesn't become an ABI
> > for people that don't already rely in this information. How about
> > adding a check the code adds the linux,atags property to do it
> > only for a whitelist of board numbers?
> 
> Or populate /proc/atags only for the ones that need it from machine
> specific init_early?

That would also address my main concern about /proc/atags, but still
leave the atags in /proc/device-tree/chosen/linux,atags, and it would
be bad if someone who currently uses /proc/atags changes their code
to use the other file instead of finding a proper solution.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277819 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Multipart message — attachments visible in raw view] — view raw

On Wednesday 25 November 2015 22:29:53 Arnd Bergmann wrote:
> On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [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 boards that need it, as an opt-in. That way it doesn't
> > > become an ABI for people that don't already rely in this
> > > information. How about adding a check the code adds the
> > > linux,atags property to do it only for a whitelist of board
> > > numbers?
> > 
> > Or populate /proc/atags only for the ones that need it from machine
> > specific init_early?
> 
> That would also address my main concern about /proc/atags, but still
> leave the atags in /proc/device-tree/chosen/linux,atags, and it would
> be bad if someone who currently uses /proc/atags changes their code
> to use the other file instead of finding a proper solution.
> 
> 	Arnd

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 could properly read those custom information from 
bootloader?

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1277823 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

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 could properly read those custom information from 
> bootloader?

The typical solution for nonstandard bootloaders is to have a boot wrapper
like the one from https://github.com/zonque/pxa-impedance-matcher that
translates whatever information we have at the bootloader level into
DT properties.

As I understand, the reason we are not doing that here is that we also
have proprietary user space that we can't fix to look in a different
place, i.e. the interface is between the bootloader and some user
binary, not bootloader to kernel.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277833 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Multipart message — attachments visible in raw view] — view raw

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 booted kernel via custom
> > specific ATAGs fields. How userspace could properly read those
> > custom information from bootloader?
> 
> The typical solution for nonstandard bootloaders is to have a boot
> wrapper like the one from
> https://github.com/zonque/pxa-impedance-matcher that translates
> whatever information we have at the bootloader level into DT
> properties.
> 

Ok. So there is no better solution. With some hacks we can use U-Boot as 
3rd stage bootloader. But this is not useful for debugging or 
developing...

Ideal "wrapper" solution would be to compile wrapper and linux zImage 
and then glue them together to one binary. Something like internal linux 
uncompress code which translate atags to dt.

> As I understand, the reason we are not doing that here is that we
> also have proprietary user space that we can't fix to look in a
> different place, i.e. the interface is between the bootloader and
> some user binary, not bootloader to kernel.
> 

Yes, proprietary/closed applications are problems which we cannot fix 
(without rewriting them).

New applications could use new "proper" interface. But without that 
interface we cannot do that.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1277968 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On 11/25/2015 1:03 PM, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [151125 11:50]:
>> On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
>>> * Pali Rohár <pali.rohar@gmail.com> [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 11/5/2015 8:17 AM, Tony Lindgren wrote:
>>>>>>> * Pali Rohár <pali.rohar@gmail.com> [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 <pali.rohar@gmail.com> [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.
>>>>>>
>>>>>> I'm not real happy with the concept of patches 4 and 5 in this series.
>>>>>> My concern is that those two patches are using the FDT as a transport
>>>>>> mechanism for a binary blob (the atags object).
>>>>>
>>>>> Umm. Ok. Do you have alternative proposal that works for everyone?
>>>>>
>>>>> I mean. This discussion was going for quite a long time, and it would
>>>>> be nice to have some solution... patch proposal... something.
>>>>>                                                                     Pavel
>>>>
>>>> Yes, discussion is going for a long time! So should I spend time for
>>>> adding documentation to my solution (this is last one thing which is
>>>> missing)? Or my solution is wrong and somebody else will propose new?
>>>> I do not want to spend time on something which will be rejected and
>>>> discarded.
>>>
>>> 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
>> boards that need it, as an opt-in. That way it doesn't become an ABI

The feature (in whatever form it takes) should be definitely be highly
restricted and marked as deprecated.

>> for people that don't already rely in this information. How about
>> adding a check the code adds the linux,atags property to do it
>> only for a whitelist of board numbers?
> 
> 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():

    Are the ATAGs at a fixed address on the N900?  Can that be handled in
    some kind of legacy file for the N900 which calls save_atags() on it, so
    we don't end up introducing yet more stuff that we have to maintain into
    the distant future?  If not, what about copying a known working atag
    structure into a legacy file for the N900?

It seems to me that patches 1, 2, 4, and 5 could be replaced by this
approach.

Regards,

Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278095

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():
> 
>     Are the ATAGs at a fixed address on the N900?  Can that be handled in
>     some kind of legacy file for the N900 which calls save_atags() on it, so
>     we don't end up introducing yet more stuff that we have to maintain into
>     the distant future?  If not, what about copying a known working atag
>     structure into a legacy file for the N900?
> 
> It seems to me that patches 1, 2, 4, and 5 could be replaced by this
> approach.

Hi Frank, in this case I will ask my question again: It is possible to
read atags from that legacy file. And if yes how? I was not thinking
about this approach because somebody in past wrote that this is not
possible...

-- 
Pali Rohár
pali.rohar@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278444

* Pali Rohár <pali.rohar@gmail.com> [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 for the N900 which calls save_atags():
> > 
> >     Are the ATAGs at a fixed address on the N900?  Can that be handled in
> >     some kind of legacy file for the N900 which calls save_atags() on it, so
> >     we don't end up introducing yet more stuff that we have to maintain into
> >     the distant future?  If not, what about copying a known working atag
> >     structure into a legacy file for the N900?
> > 
> > It seems to me that patches 1, 2, 4, and 5 could be replaced by this
> > approach.
> 
> Hi Frank, in this case I will ask my question again: It is possible to
> read atags from that legacy file. And if yes how? I was not thinking
> about this approach because somebody in past wrote that this is not
> possible...

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..

That would work as long as the kernel no longer needs it.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278454

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 driver to be accepted upstream? As IIRC 
the current situation is because similar driver was rejected. Might be 
wrong as well, it was about 2-3 years ago.

Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278627

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 dynamically create that blob file in /lib/firmware? If
kernel does not export those atags (somehow) from bootloader, then
userspace is not able to create that blob... cyclic problem.

So no, problem is that bootloader provides via custom atags dynamic
information like: boot reason (how was device started, by rtc alarm? by
reboot? by usb charger? by power button?), boot mode (should be enter
into firmware update mode?, is this normal boot mode?), ... and those
information are needed for some proprietary software (e.g. firmware
upgrade/flash) but also by any other open source applications (based on
usb charger we enter different runlevel -- for just only charging
device).

-- 
Pali Rohár
pali.rohar@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278644

Hi

On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár <pali.rohar@gmail.com> 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 the atags should be done by
>> the driver..
>
> And who can dynamically create that blob file in /lib/firmware? If
> kernel does not export those atags (somehow) from bootloader, then
> userspace is not able to create that blob... cyclic problem.
>

Are those atags from bootloader fix or they change device by device. If they
are fixed they can be included in some firmware and get from the disk.

Michael

> So no, problem is that bootloader provides via custom atags dynamic
> information like: boot reason (how was device started, by rtc alarm? by
> reboot? by usb charger? by power button?), boot mode (should be enter
> into firmware update mode?, is this normal boot mode?), ... and those
> information are needed for some proprietary software (e.g. firmware
> upgrade/flash) but also by any other open source applications (based on
> usb charger we enter different runlevel -- for just only charging
> device).
>
> --
> Pali Rohár
> pali.rohar@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278656

Hi

On Fri, Nov 27, 2015 at 9:44 AM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> Hi
>
> On Fri, Nov 27, 2015 at 9:38 AM, Pali Rohár <pali.rohar@gmail.com> 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 the atags should be done by
>>> the driver..
>>
>> And who can dynamically create that blob file in /lib/firmware? If
>> kernel does not export those atags (somehow) from bootloader, then
>> userspace is not able to create that blob... cyclic problem.
>>
>
> Are those atags from bootloader fix or they change device by device. If they
> are fixed they can be included in some firmware and get from the disk.
>

Sorry, miss the second part of email ;)

Michael

> Michael
>
>> So no, problem is that bootloader provides via custom atags dynamic
>> information like: boot reason (how was device started, by rtc alarm? by
>> reboot? by usb charger? by power button?), boot mode (should be enter
>> into firmware update mode?, is this normal boot mode?), ... and those
>> information are needed for some proprietary software (e.g. firmware
>> upgrade/flash) but also by any other open source applications (based on
>> usb charger we enter different runlevel -- for just only charging
>> device).
>>
>> --
>> Pali Rohár
>> pali.rohar@gmail.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278832

* Pali Rohár <pali.rohar@gmail.com> [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 done by
> > the driver..
> 
> And who can dynamically create that blob file in /lib/firmware? If
> kernel does not export those atags (somehow) from bootloader, then
> userspace is not able to create that blob... cyclic problem.
> 
> So no, problem is that bootloader provides via custom atags dynamic
> information like: boot reason (how was device started, by rtc alarm? by
> reboot? by usb charger? by power button?), boot mode (should be enter
> into firmware update mode?, is this normal boot mode?), ... and those
> information are needed for some proprietary software (e.g. firmware
> upgrade/flash) but also by any other open source applications (based on
> usb charger we enter different runlevel -- for just only charging
> device).

OK if the ATAGs are not static then naturally we can't create the blobs
then.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278800

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
> > he suggested a legacy file for the N900 which calls save_atags():
> > 
> >     Are the ATAGs at a fixed address on the N900?  Can that be handled in
> >     some kind of legacy file for the N900 which calls save_atags() on it, so
> >     we don't end up introducing yet more stuff that we have to maintain into
> >     the distant future?  If not, what about copying a known working atag
> >     structure into a legacy file for the N900?
> > 
> > It seems to me that patches 1, 2, 4, and 5 could be replaced by this
> > approach.
> 
> Hi Frank, in this case I will ask my question again: It is possible to
> read atags from that legacy file. And if yes how? I was not thinking
> about this approach because somebody in past wrote that this is not
> possible...

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 you have to arrange for the preloaded object to be used by the
linker, and the additional overhead it places on the intercepted
functions.

Eg,

openatags.c:

#define open libc_open
#include <fcntl.h>
#undef open
#include <string.h>

int open(const char *pathname, int flags, mode_t mode)
{
        static int (*old_open)(const char *pathname, int flags, mode_t mode);

        if (strcmp(pathname, "/proc/atags") == 0)
		pathname = "/tmp/my-atags";

        if (!old_open)
                old_open = dlsym(RTLD_NEXT, "open");

        return old_open(pathname, flags, mode);
}

Build the above (untested) with:
gcc -O2 -o openatags.o -c openatags.c
gcc -shared -o openatags.so openatags.o -ldl

Now, when running one of these programs, you can test it with:
LD_PRELOAD=openatags.so /name/of/program

You could also list the full pathname to openatags.so in /etc/ld.so.preload,
but test it first, because it will always be used by the linker in that
case, and you wouldn't want normal commands to misbehave.

Note that putting it in /etc/ld.so.preload will also have the effect that
cat /proc/atags will also get redirected to /tmp/my-atags too.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278939

On Fri, Nov 27, 2015 at 01:27:23PM +0000, 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 you have to arrange for the preloaded object to be used by the
> linker, and the additional overhead it places on the intercepted
> functions.

Another idea if people don't like the preload idea.

We could create a zero-sized /proc/atags, and then use a bind mount in
userspace to bind some other file containing the required information
on top.  That could even be the atag blob from /sys/firmware/whatever.
The N700 (or whatever platform needs it) could be responsible for
creating the zero-sized /proc/atags so that we don't have it everywhere.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278970 — Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Friday 27 November 2015 19:51:48 Russell King - ARM Linux wrote:
> On Fri, Nov 27, 2015 at 01:27:23PM +0000, 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 you have to arrange for the preloaded object to be used by the
> > linker, and the additional overhead it places on the intercepted
> > functions.
> 
> Another idea if people don't like the preload idea.
> 
> We could create a zero-sized /proc/atags, and then use a bind mount in
> userspace to bind some other file containing the required information
> on top.  That could even be the atag blob from /sys/firmware/whatever.
> The N700 (or whatever platform needs it) could be responsible for
> creating the zero-sized /proc/atags so that we don't have it everywhere.

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 (and not much more) seems reasonable
here, as we are talking about a board specific hack and the whole point
appears to be running unmodified user space.

Regarding how to get the data into the kernel in the first place, my
preferred choice would still be to have an intermediate bootloader
such as pxa-impedance-matcher, but I won't complain if others are
happy enough about putting it into the ATAGS compat code we already
have, as long as it's limited to the boards we know need it.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web