Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1274798 > unrolled thread
| Started by | Pavel Machek <pavel@ucw.cz> |
|---|---|
| First post | 2015-11-22 08:00 +0100 |
| Last post | 2015-11-30 01:20 +0100 |
| Articles | 11 on this page of 31 — 9 participants |
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.
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 2 of 2 — ← Prev page 1 [2]
| From | Nicolas Pitre <nicolas.pitre@linaro.org> |
|---|---|
| Date | 2015-11-28 00:30 +0100 |
| Message-ID | <qzACK-Q6-7@gated-at.bofh.it> |
| In reply to | #1278970 |
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 (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. Assuming you have a N700 board file for special procfs code, then why not getting at the atags in memory where the bootloader has put them directly from that same board file? This way it'll really be limited to the board we know needs it and the special exception will be contained to that one file. Amongst the machine specific hooks, there is one that gets invoked early during boot before those atags are overwritten. Nicolas -- 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]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2015-11-28 13:30 +0100 |
| Subject | Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry |
| Message-ID | <qzMNz-oi-11@gated-at.bofh.it> |
| In reply to | #1279041 |
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 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. > > Assuming you have a N700 board file for special procfs code, then why > not getting at the atags in memory where the bootloader has put them > directly from that same board file? This way it'll really be limited to > the board we know needs it and the special exception will be contained > to that one file. Amongst the machine specific hooks, there is one that > gets invoked early during boot before those atags are overwritten. I didn't realize this was possible, as we don't know the atags pointer when we instead get a DTB pointer. However you are right: the board file knows exactly that the atag_offset is 0x100, so we can grab it from there, and that will make the implementation really easy and contained to a single file that has access to the atags and that can create the /proc/atags file for 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]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-28 14:00 +0100 |
| Message-ID | <qzNgB-zv-9@gated-at.bofh.it> |
| In reply to | #1279137 |
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 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. > > > > Assuming you have a N700 board file for special procfs code, then why > > not getting at the atags in memory where the bootloader has put them > > directly from that same board file? This way it'll really be limited to > > the board we know needs it and the special exception will be contained > > to that one file. Amongst the machine specific hooks, there is one that > > gets invoked early during boot before those atags are overwritten. > > I didn't realize this was possible, as we don't know the atags pointer > when we instead get a DTB pointer. However you are right: the board > file knows exactly that the atag_offset is 0x100, so we can grab it > from there, and that will make the implementation really easy and > contained to a single file that has access to the atags and that > can create the /proc/atags file for it. I've made several suggestions over the year or so that this problem has been around, and solving this problem appears to be getting nowhere... (because we _still_ have the problem today.) When the same suggestions start to be made by other people, I think there's not much more that can be done to help resolve the situation. It's probably time to walk away from the problem, and let those who are supposedly motivated to use these troublesome platforms just get on with it. I'm not sure what Tony does at this point: if he rips out the non-DT OMAP code, it'll cause a regression, but at the same time, it provides additional motivation to get the problem resolved. I can quite well see Pavel going off and whinging at Linus, Linus getting stressed at us for intentionally breaking something that used to work, and telling everyone that they shouldn't be working on the kernel, in his usual friendly way. So, I think if the non-DT OMAP stuff is getting in the way of further OMAP development, then the only solution is to put pressure on those who are holding it up: in other words, put pressure on those to get this damned problem solved. The only thing I can think of doing is to give the N900 people notice that they're causing a problem here, explaining exactly why - maybe explaining that it's been causing a problem however long it has and that the only option is going to be to fork mainline and effectively leave the code in mainline unmaintained because of this. Then, of course, those who have caused this situation then get the fun job of maintaining _all_ the OMAP code in mainline on their own, which I think would bury them under such a huge mountain that the code would end up being terminally broken, and ripe for deletion. At which point, it'd make sense to merge the maintained fork back into mainline, which of course wouldn't have the troublesome code platforms by that time. :) Yes, it's not particularly nice, but I don't see this problem getting resolved. (Maybe this email will be enough to motivate the N900 users to sort this out, but I suspect they'll prefer to spend time whinging and moaning at me in email rather than doing what needs to be done and fixing the problem.) -- 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]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-28 13:40 +0100 |
| Message-ID | <qzMXf-rE-11@gated-at.bofh.it> |
| In reply to | #1279041 |
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. 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. > > Assuming you have a N700 board file for special procfs code, then why > not getting at the atags in memory where the bootloader has put them > directly from that same board file? This way it'll really be limited to > the board we know needs it and the special exception will be contained > to that one file. Amongst the machine specific hooks, there is one that > gets invoked early during boot before those atags are overwritten. I've already suggested that. -- 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]
| From | Nicolas Pitre <nicolas.pitre@linaro.org> |
|---|---|
| Date | 2015-11-28 18:40 +0100 |
| Message-ID | <qzRDA-3lI-19@gated-at.bofh.it> |
| In reply to | #1279138 |
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 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. > > > > Assuming you have a N700 board file for special procfs code, then why > > not getting at the atags in memory where the bootloader has put them > > directly from that same board file? This way it'll really be limited to > > the board we know needs it and the special exception will be contained > > to that one file. Amongst the machine specific hooks, there is one that > > gets invoked early during boot before those atags are overwritten. > > I've already suggested that. Good. And Arnd likes the idea too. So we might be converging at last which is a good thing. Nicolas -- 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]
| From | Frank Rowand <frowand.list@gmail.com> |
|---|---|
| Date | 2015-11-28 22:10 +0100 |
| Subject | Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry |
| Message-ID | <qzUUN-5Bl-5@gated-at.bofh.it> |
| In reply to | #1279187 |
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 >>>> 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. >>> >>> Assuming you have a N700 board file for special procfs code, then why >>> not getting at the atags in memory where the bootloader has put them >>> directly from that same board file? This way it'll really be limited to >>> the board we know needs it and the special exception will be contained >>> to that one file. Amongst the machine specific hooks, there is one that >>> gets invoked early during boot before those atags are overwritten. >> >> I've already suggested that. > > Good. And Arnd likes the idea too. So we might be converging at last > which is a good thing. It makes me happy too. -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]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-29 19:20 +0100 |
| Message-ID | <qAeJP-175-3@gated-at.bofh.it> |
| In reply to | #1279187 |
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 7th, from earlier in this very thread: Pali: > Me: > > Are the ATAGs at a fixed address on the N900? > > Yes, in board-rx51.c is: > > .atag_offset = 0x100 > > and Nokia Bootloader (proprietary) store them to that address. > > > 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? > > > > I already asked question if it is possible to read ATAGs from DT booted > kernel. And somebody (do not remember who) wrote to ML, that it is not > possible and it can be done in that uncompress code. So you're converging on an idea that has already been rejected. That's not a good thing, IMHO. -- 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]
| From | Pali Rohár <pali.rohar@gmail.com> |
|---|---|
| Date | 2015-11-29 19:20 +0100 |
| Subject | Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry |
| Message-ID | <qAeJQ-175-13@gated-at.bofh.it> |
| In reply to | #1279386 |
[Multipart message — attachments visible in raw view] — view raw
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 might be > convergence towards an idea, but... Here's a mail extract, from July > 7th, from earlier in this very thread: > > Pali: > > Me: > > > Are the ATAGs at a fixed address on the N900? > > > > Yes, in board-rx51.c is: > > > > .atag_offset = 0x100 > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > 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? > > > > I already asked question if it is possible to read ATAGs from DT > > booted kernel. And somebody (do not remember who) wrote to ML, > > that it is not possible and it can be done in that uncompress > > code. > > So you're converging on an idea that has already been rejected. > That's not a good thing, IMHO. Or in other case show that such implementation is possible... -- Pali Rohár pali.rohar@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-11-30 00:20 +0100 |
| Message-ID | <qAjq9-3ZG-3@gated-at.bofh.it> |
| In reply to | #1279389 |
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. > > > > I disagree with the idea that there is convergence. There might be > > convergence towards an idea, but... Here's a mail extract, from July > > 7th, from earlier in this very thread: > > > > Pali: > > > Me: > > > > Are the ATAGs at a fixed address on the N900? > > > > > > Yes, in board-rx51.c is: > > > > > > .atag_offset = 0x100 > > > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > > > 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? > > > > > > I already asked question if it is possible to read ATAGs from DT > > > booted kernel. And somebody (do not remember who) wrote to ML, > > > that it is not possible and it can be done in that uncompress > > > code. > > > > So you're converging on an idea that has already been rejected. > > That's not a good thing, IMHO. > > Or in other case show that such implementation is possible... Only those with the problem can do that. -- 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]
| From | Pali Rohár <pali.rohar@gmail.com> |
|---|---|
| Date | 2015-11-30 01:20 +0100 |
| Subject | Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry |
| Message-ID | <qAkme-4zV-3@gated-at.bofh.it> |
| In reply to | #1279386 |
[Multipart message — attachments visible in raw view] — view raw
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 disagree with the idea that there is convergence. There might be > > convergence towards an idea, but... Here's a mail extract, from > > July 7th, from earlier in this very thread: > > > > Pali: > > > Me: > > > > Are the ATAGs at a fixed address on the N900? > > > > > > Yes, in board-rx51.c is: > > > > > > .atag_offset = 0x100 > > > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > > > 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? > > > > > > I already asked question if it is possible to read ATAGs from DT > > > booted kernel. And somebody (do not remember who) wrote to ML, > > > that it is not possible and it can be done in that uncompress > > > code. > > Who is that somebody? If ever it happened to be me then objection is > withdrawn. Otherwise that somebody should come forth and speak up > again. > ... do not remember ... this discussion were in more email threads and takes more then one year... sorry but my memory is not excellent -- Pali Rohár pali.rohar@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Nicolas Pitre <nicolas.pitre@linaro.org> |
|---|---|
| Date | 2015-11-30 01:20 +0100 |
| Message-ID | <qAkme-4zV-5@gated-at.bofh.it> |
| In reply to | #1279386 |
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 > convergence towards an idea, but... Here's a mail extract, from July > 7th, from earlier in this very thread: > > Pali: > > Me: > > > Are the ATAGs at a fixed address on the N900? > > > > Yes, in board-rx51.c is: > > > > .atag_offset = 0x100 > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > 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? > > > > > > > I already asked question if it is possible to read ATAGs from DT booted > > kernel. And somebody (do not remember who) wrote to ML, that it is not > > possible and it can be done in that uncompress code. Who is that somebody? If ever it happened to be me then objection is withdrawn. Otherwise that somebody should come forth and speak up again. > So you're converging on an idea that has already been rejected. That's > not a good thing, IMHO. All the alternatives are worse and being rejected as well. In that case we should settle on the idea that satisfies the most people. Nicolas -- 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] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web