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

Groups > linux.kernel > #1291977 > 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 Pali Rohár <pali.rohar@gmail.com> - 2015-12-15 10:40 +0100
    Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry Arnd Bergmann <arnd@arndb.de> - 2015-12-15 12: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-12-15 13:30 +0100
      Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT  "/chosen/linux,atags" entry Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-12-15 18:30 +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-12-23 16:00 +0100

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

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 <pali.rohar@gmail.com> [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 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
> > > 
> > > Yes this certainly seems like the best solution. I think we got into
> > > the atags-to-dt track as some of the atags are already being translated.
> > > 
> > > In this case there's no need to translate them AFAIK. You can just
> > > parse them and have them available for the user space. So as long as
> > > nothing trashes the atags at the atag_offset, you should be able to
> > > call a function to parse them in the n900 specific init_machine.
> > > 
> > > Regards,
> > > 
> > > Tony
> > 
> > In arch/arm/kernel/setup.c is function setup_arch() and it calls:
> > 
> >   mdesc = setup_machine_fdt(__atags_pointer);
> >   if (!mdesc)
> >       mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> > 
> > So it looks like that on atags address is stored either atags structure
> > or DT structure... so it is truth kernel uncompress code put DT blob to
> > same offset where is expected atags structure?
> 
> No.  It doesn't put it anywhere. Those functions read DT/ATAGs from the 
> passed address.  But you know this address won't be the one you want for 
> the legacy ATAGs.
> 
> What you should do is to add a init_early hook to your mdesc structure 
> and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100.
> 
> Now I suspect paging_init() marks the point where the ATAGs will be 
> overwritten.  To prevent this, you might have to add an additional tweak 
> in arm_mm_memblock_reserve() similar to the one already present for 
> CONFIG_SA1111. Something like:
> 
> 	memblock_reserve(PHYS_OFFSET, PAGE_SIZE);
> 
> And later on you can return that page back to the system.
> 
> 
> Nicolas

So am I understand correctly that solution would be to hack
arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?

And should be this just when when we detect Nokia N900 in DT? Or for all
OMAP2 boards? Or all ARM boards?

-- 
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] | [next] | [standalone]

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

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 <pali.rohar@gmail.com> [151129 16:16]:
> > > > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > In arch/arm/kernel/setup.c is function setup_arch() and it calls:
> > > 
> > >   mdesc = setup_machine_fdt(__atags_pointer);
> > >   if (!mdesc)
> > >       mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> > > 
> > > So it looks like that on atags address is stored either atags structure
> > > or DT structure... so it is truth kernel uncompress code put DT blob to
> > > same offset where is expected atags structure?
> > 
> > No.  It doesn't put it anywhere. Those functions read DT/ATAGs from the 
> > passed address.  But you know this address won't be the one you want for 
> > the legacy ATAGs.
> > 
> > What you should do is to add a init_early hook to your mdesc structure 
> > and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100.
> > 
> > Now I suspect paging_init() marks the point where the ATAGs will be 
> > overwritten.  To prevent this, you might have to add an additional tweak 
> > in arm_mm_memblock_reserve() similar to the one already present for 
> > CONFIG_SA1111. Something like:
> > 
> >       memblock_reserve(PHYS_OFFSET, PAGE_SIZE);
> > 
> > And later on you can return that page back to the system.
> > 
> 
> So am I understand correctly that solution would be to hack
> arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?

I would think we can just copy the data from PAGE_OFFSET + 0x100
to a some other page from your init_early hook. IIRC you can't use
kmalloc there, but memblock_alloc() should work.

	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]

#1292104

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 want to reserve the memory, then you have the ->reserve callback,
where you can call:

	memblock_reserve(PHYS_OFFSET, PAGE_SIZE);

if you wish to prevent the first page being overwritten.  You're then
responsible for freeing this page later in the boot sequence, or you
could just keep it around and refer to the atags in that page directly.

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.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
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]

#1292381

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

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 platform hooks to cope
> with whatever the platform requires.

Indeed.  I didn't notice that mdesc->reserve() exists these days and is 
perfect for this purpose as you say.


Nicolas

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

#1297499

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 correctly, proper patch 
will follow if that's the case):

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 34ff14b..8916856 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -83,8 +83,25 @@ static const char *const n900_boards_compat[] 
__initconst = {
         NULL,
  };

+#ifdef CONFIG_ATAGS_PROC
+extern void save_atags(const struct tag *tags);
+
+/* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
+ * save them while the data is still not overwritten
+ */
+static void __init rx51_reserve(void)
+{
+       const phys_addr_t __atags_pointer = 0x100;
+
+       save_atags(phys_to_virt(__atags_pointer));
+       omap_reserve();
+}
+#else
+#define rx51_reserve omap_reserve
+#endif
+
  DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
-       .reserve        = omap_reserve,
+       .reserve        = rx51_reserve,
         .map_io         = omap3_map_io,
         .init_early     = omap3430_init_early,
         .init_machine   = omap_generic_init,
--
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]

Back to top | Article view | linux.kernel

csiph-web