Armada XP Internal registers

Armada XP Internal registers

[Matthew Minter]

I recently had to upgrade the boot loader on my Armada XP GP board (as
I could not get the sources for the old version, only the binaries for
the SPI flash version and needed to build a bootloader to boot from
NAND flash).

After upgrading I experienced a number of problems on both the mvebu tree and
Ezequiel Garcia's v2 NAND develoment tree (here
https://github.com/MISL-EBU-System-SW/mainline-public/tree/l2-mtd/upstream-nand-v2)
(which otherwise runs really well, so thanks)

However I do not think it is the fault of either kernel. Specifically
it seems the new bootloader is sticking the internal registers at
0xf1000000 instead of 0xd0000000. Specifically this was causing the
kernel to oops and then panic when trying to init the IRQ or serial
uart.

It seems that changing the armada-xp-gp device tree to read:
        soc {
                ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
                          MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
                          MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;


instead of:
        soc {
                ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
                          MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
                          MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;

causes the chip to get further in boot, however at this point I found
another issue. The kernel was experiencing another oops (which was
killing either init or the idle process) due to an error "Unhandled
fault: external abort on non-linefetch (0x808) at 0xf0144010"

I again managed to get past this by not configuring the serial port on
the kernel command line however this has the significant drawback that
I do not get any messages from the kernel or my init system over
serial and the terminal remains blank until a getty eventually spawns.
This makes other boot issues hard to debug.

I am not completely sure if this is a boot-loader issue, a kernel
issue or my own misconfiguration. However I can make the chip boot so
it is not too urgent, just introduces annoying limitations.

If anyone has any ideas on this I would be very grateful, best regards,
Matthew

-- 


------------------------------
For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com

------------------------------

Armada XP Internal registers

[Matthew Minter]

In amendment to before, I missed a small factual detail, to cause a
successful boot I do have to specify a boot console (ttys0) just not
specify a baud rate. for example "console=ttyS0" as opposed to
"console=ttyS0,115200" to cause it to boot, but even then no boot
command line works.

On 21 October 2013 15:47, Matthew Minter <matthew_minter@xyratex.com> wrote:
> I recently had to upgrade the boot loader on my Armada XP GP board (as
> I could not get the sources for the old version, only the binaries for
> the SPI flash version and needed to build a bootloader to boot from
> NAND flash).
>
> After upgrading I experienced a number of problems on both the mvebu tree and
> Ezequiel Garcia's v2 NAND develoment tree (here
> https://github.com/MISL-EBU-System-SW/mainline-public/tree/l2-mtd/upstream-nand-v2)
> (which otherwise runs really well, so thanks)
>
> However I do not think it is the fault of either kernel. Specifically
> it seems the new bootloader is sticking the internal registers at
> 0xf1000000 instead of 0xd0000000. Specifically this was causing the
> kernel to oops and then panic when trying to init the IRQ or serial
> uart.
>
> It seems that changing the armada-xp-gp device tree to read:
>         soc {
>                 ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
>                           MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>                           MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
>
>
> instead of:
>         soc {
>                 ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
>                           MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>                           MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
>
> causes the chip to get further in boot, however at this point I found
> another issue. The kernel was experiencing another oops (which was
> killing either init or the idle process) due to an error "Unhandled
> fault: external abort on non-linefetch (0x808) at 0xf0144010"
>
> I again managed to get past this by not configuring the serial port on
> the kernel command line however this has the significant drawback that
> I do not get any messages from the kernel or my init system over
> serial and the terminal remains blank until a getty eventually spawns.
> This makes other boot issues hard to debug.
>
> I am not completely sure if this is a boot-loader issue, a kernel
> issue or my own misconfiguration. However I can make the chip boot so
> it is not too urgent, just introduces annoying limitations.
>
> If anyone has any ideas on this I would be very grateful, best regards,
> Matthew

-- 


------------------------------
For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com

------------------------------

Armada XP Internal registers

[Ezequiel Garcia]

Matthew,

On Mon, Oct 21, 2013 at 03:47:43PM +0100, Matthew Minter wrote:
> I recently had to upgrade the boot loader on my Armada XP GP board (as
> I could not get the sources for the old version, only the binaries for
> the SPI flash version and needed to build a bootloader to boot from
> NAND flash).
> 
> After upgrading I experienced a number of problems on both the mvebu tree and
> Ezequiel Garcia's v2 NAND develoment tree (here
> https://github.com/MISL-EBU-System-SW/mainline-public/tree/l2-mtd/upstream-nand-v2)
> (which otherwise runs really well, so thanks)
> 
> However I do not think it is the fault of either kernel. Specifically
> it seems the new bootloader is sticking the internal registers at
> 0xf1000000 instead of 0xd0000000. Specifically this was causing the
> kernel to oops and then panic when trying to init the IRQ or serial
> uart.
> 
> It seems that changing the armada-xp-gp device tree to read:
>         soc {
>                 ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
>                           MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>                           MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
> 
> 
> instead of:
>         soc {
>                 ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
>                           MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>                           MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
> 
> causes the chip to get further in boot, however at this point I found
> another issue. The kernel was experiencing another oops (which was
> killing either init or the idle process) due to an error "Unhandled
> fault: external abort on non-linefetch (0x808) at 0xf0144010"
> 
> I again managed to get past this by not configuring the serial port on
> the kernel command line however this has the significant drawback that
> I do not get any messages from the kernel or my init system over
> serial and the terminal remains blank until a getty eventually spawns.
> This makes other boot issues hard to debug.
> 
> I am not completely sure if this is a boot-loader issue, a kernel
> issue or my own misconfiguration. However I can make the chip boot so
> it is not too urgent, just introduces annoying limitations.
> 
> If anyone has any ideas on this I would be very grateful, best regards,

Hm.. so if you upgraded the bootloader and the internal register address
is now 0xf100000 then it makes sense to fix your DT accordingly.

First of all, I think you're safer trying some very recent upstream
tag, such as v3.12-rc5. At least until you can pinpoint your issue
it will be best to use that kernel.

Are you enabling CONFIG_DEBUG_LL? In that case, please note there's a
new option that will let you move to the 'new' internal regs address.

Thomas and Gregory might know better, but they might be a little
unresponsive so please bare with me as I haven't tried the new internal
register address yet.

Anyway, please double-check that option and send me the full kernel log
(until it hangs or panics) and the also the full config.

Regards,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Armada XP Internal registers

[Jason Cooper]

Hi Matthew,

On Mon, Oct 21, 2013 at 02:43:40PM -0300, Ezequiel Garcia wrote:
> On Mon, Oct 21, 2013 at 03:47:43PM +0100, Matthew Minter wrote:
> > I recently had to upgrade the boot loader on my Armada XP GP board (as
> > I could not get the sources for the old version, only the binaries for
> > the SPI flash version and needed to build a bootloader to boot from
> > NAND flash).
> > 
> > After upgrading I experienced a number of problems on both the mvebu tree and
> > Ezequiel Garcia's v2 NAND develoment tree (here
> > https://github.com/MISL-EBU-System-SW/mainline-public/tree/l2-mtd/upstream-nand-v2)
> > (which otherwise runs really well, so thanks)
> > 
> > However I do not think it is the fault of either kernel. Specifically
> > it seems the new bootloader is sticking the internal registers at
> > 0xf1000000 instead of 0xd0000000. Specifically this was causing the
> > kernel to oops and then panic when trying to init the IRQ or serial
> > uart.
> > 
> > It seems that changing the armada-xp-gp device tree to read:
> >         soc {
> >                 ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
> >                           MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> >                           MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
> > 
> > 
> > instead of:
> >         soc {
> >                 ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
> >                           MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> >                           MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
> > 
> > causes the chip to get further in boot, however at this point I found
> > another issue. The kernel was experiencing another oops (which was
> > killing either init or the idle process) due to an error "Unhandled
> > fault: external abort on non-linefetch (0x808) at 0xf0144010"
> > 
> > I again managed to get past this by not configuring the serial port on
> > the kernel command line however this has the significant drawback that
> > I do not get any messages from the kernel or my init system over
> > serial and the terminal remains blank until a getty eventually spawns.
> > This makes other boot issues hard to debug.
> > 
> > I am not completely sure if this is a boot-loader issue, a kernel
> > issue or my own misconfiguration. However I can make the chip boot so
> > it is not too urgent, just introduces annoying limitations.
> > 
> > If anyone has any ideas on this I would be very grateful, best regards,
> 
> Hm.. so if you upgraded the bootloader and the internal register address
> is now 0xf100000 then it makes sense to fix your DT accordingly.

Agreed.

> Are you enabling CONFIG_DEBUG_LL? In that case, please note there's a
> new option that will let you move to the 'new' internal regs address.

The option is CONFIG_DEBUG_MVEBU_UART.  Since you swapped out the
bootloader, you need to tell it so.  (Early printk assumes the
bootloader setup the uart and just writes to it blindly.  If it's at a
different address than expected, it'll crash.)

hth,

Jason.

Armada XP Internal registers

[Thomas Petazzoni]

Jason, Matthew,

On Mon, 21 Oct 2013 14:42:19 -0400, Jason Cooper wrote:

> > Hm.. so if you upgraded the bootloader and the internal register address
> > is now 0xf100000 then it makes sense to fix your DT accordingly.
> 
> Agreed.
> 
> > Are you enabling CONFIG_DEBUG_LL? In that case, please note there's a
> > new option that will let you move to the 'new' internal regs address.
> 
> The option is CONFIG_DEBUG_MVEBU_UART.  Since you swapped out the
> bootloader, you need to tell it so.  (Early printk assumes the
> bootloader setup the uart and just writes to it blindly.  If it's at a
> different address than expected, it'll crash.)

I do confirm what Ezequiel and Jason said. The earlier U-Boot versions
from Marvell remapped the registers at 0xd0000000, while the more
recent versions remap the registers at 0xf1000000.

In recent kernel versions (I guess since 3.10 or 3.11), we've made sure
that changing the DT Mbus informations was enough to switch the entire
kernel to use the correct internal register base address. With the
exception of DEBUG_LL, which can't really on the DT, so that's why we
have two separate Kconfig options, one for 0xd0000000 and another one
for 0xf1000000.

That being said, I don't think the issue Matthew is seeing is related
to improper DEBUG_LL configuration. He wouldn't be getting "Unhandled
fault: external abort on non-linefetch (0x808) at 0xf0144010". He would
simply be getting *nothing* if the DEBUG_LL configuration was wrong.

Matthew, can you tell me which U-Boot version exactly you're using, and
give me the diff of the changes you've made to your Device Tree, so I
can see if I can reproduce the problem? For what it's worth, register
0x44010 is part of the PCIe registers, but I don't see right now what
could be the reason for the problem you're seeing.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Armada XP Internal registers

[Matthew Minter]

Hi guys,

I am preparing all the requested info and will send it to the list
soon, unfortunately I am away from the office right now so cant sent
it immediately (I don't have my serial logs on this computer) but will
send all the data as soon as I can.

Best regards,
Matthew

On 22 October 2013 14:29, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Jason, Matthew,
>
> On Mon, 21 Oct 2013 14:42:19 -0400, Jason Cooper wrote:
>
>> > Hm.. so if you upgraded the bootloader and the internal register address
>> > is now 0xf100000 then it makes sense to fix your DT accordingly.
>>
>> Agreed.
>>
>> > Are you enabling CONFIG_DEBUG_LL? In that case, please note there's a
>> > new option that will let you move to the 'new' internal regs address.
>>
>> The option is CONFIG_DEBUG_MVEBU_UART.  Since you swapped out the
>> bootloader, you need to tell it so.  (Early printk assumes the
>> bootloader setup the uart and just writes to it blindly.  If it's at a
>> different address than expected, it'll crash.)
>
> I do confirm what Ezequiel and Jason said. The earlier U-Boot versions
> from Marvell remapped the registers at 0xd0000000, while the more
> recent versions remap the registers at 0xf1000000.
>
> In recent kernel versions (I guess since 3.10 or 3.11), we've made sure
> that changing the DT Mbus informations was enough to switch the entire
> kernel to use the correct internal register base address. With the
> exception of DEBUG_LL, which can't really on the DT, so that's why we
> have two separate Kconfig options, one for 0xd0000000 and another one
> for 0xf1000000.
>
> That being said, I don't think the issue Matthew is seeing is related
> to improper DEBUG_LL configuration. He wouldn't be getting "Unhandled
> fault: external abort on non-linefetch (0x808) at 0xf0144010". He would
> simply be getting *nothing* if the DEBUG_LL configuration was wrong.
>
> Matthew, can you tell me which U-Boot version exactly you're using, and
> give me the diff of the changes you've made to your Device Tree, so I
> can see if I can reproduce the problem? For what it's worth, register
> 0x44010 is part of the PCIe registers, but I don't see right now what
> could be the reason for the problem you're seeing.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 


------------------------------
For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com

------------------------------

Armada XP Internal registers

[Thomas Petazzoni]

Dear Matthew Minter,

On Tue, 22 Oct 2013 16:56:17 +0100, Matthew Minter wrote:

> I am preparing all the requested info and will send it to the list
> soon, unfortunately I am away from the office right now so cant sent
> it immediately (I don't have my serial logs on this computer) but will
> send all the data as soon as I can.

Sure, no problem. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Delivery Status Notification (Failure)

[Matthew Minter]

Hi Everyone,

I am sorry for the exceedingly long delay before replying, I have had
a number of unrelated problems which have prevented me from working on
this issue.

The version of u-boot which caused this issue was Marvell's Q2-2013
release. I used this with a 3.12 rc1 and a 3.12 rc3 kernel, both
receiving the errors I have mentioned above. I have ensured my low
level debugging configuration is correct, it is indeed mapped
correctly to the new register range and I do not believe this to be
the problem, particularly as it crashes well after the early printk
has begun giving output.

Unfortunately I cannot find the log file from the kernel at this stage
as it appears to have been filled and overwritten, I however did look
into this further and Marvell have (since when I raised the problem)
given me a patched u-boot which is no longer causing the issue (the
patch seems to be dated mid October 2013), unfortunately I cant post
the change log of the patch but it does appear the problem was caused
by a buggy u-boot release (or at least that it is fixed with the
patched version). I have since tested the new version with kernels
3.12 rc3 to 3.12 rc6 and none of them have any issues with booting.
Here is a full diff of the change I made to the device tree file (dont
mind the bogus timestamps)

--- arch/arm/boot/dts/armada-xp-gp.dts.old    2013-11-06
13:39:17.440000000 +0000
+++ arch/arm/boot/dts/armada-xp-gp.dts    2013-11-05 17:32:16.160001348 +0000
@@ -39,7 +39,7 @@
     };

     soc {
-        ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+        ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000

               MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
               MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;

I think the issue therefore may not be a kernel issue after all and
should likely not be worried about. However on a related matter, I had
thought the kernel was supposed to have some kind of detection for the
register location using cp15? Why does the device tree describe the
register address staticly if this is the case?

Ultimately I think the specific errors I was getting (along with the
exact error being variable dependant on seemingly random factors) made
the specific errors a red herring and the problem was due to a faulty
initialisation by the bootloader. However if there is any other
information I can give or if anyone is interested I may be able to
find out more.

Best regards,
Matthew

On 6 November 2013 13:58, Mail Delivery Subsystem
<mailer-daemon@googlemail.com> wrote:
> Delivery to the following recipient failed permanently:
>
>      linux-arm-kernel at lists.infradead.org
>
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the server for the recipient domain lists.infradead.org by merlin.infradead.org. [205.233.59.134].
>
> The error that the other server returned was:
> 550-Mailing lists do not accept HTML mail. See
> 550 http://david.woodhou.se/email.html
>
> ----- Original message -----
>
> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=1e100.net; s=20130820;
>         h=x-gm-message-state:mime-version:in-reply-to:references:date
>          :message-id:subject:from:to:content-type;
>         bh=7ZxkcjMOgG2fPbDIq0WtE/eu/1H9O3KEeGtX4g0cEwc=;
>         b=dxwtJYHC5DNmtLbRqHF3nOw7L6jPlkQeYBV0Lu3X+NUD50WrnLJq4LaaA3Xc8p9ZdE
>          iq9axkL33lyu7+YL41iDM+uyXrVXdGfSevUw7VKm3LemgC6aVUM8Cjv9LTJIanncySaJ
>          nlgy2K1dGUEfQffHqC3hoZp5RqCudW4JtRBGCEkkwcRZPxD4ygh09XGeJlXkciZ5xwou
>          7bBwPY1TrEqsnbMvZNW59OS6NMjePvRi4NlSSG62w7p1sbes4NnTZrzCWYKNEg0JSmdc
>          jpkoy04IypB54+95FyGFZzUOu3V3XKeTC2AvU9I/o8imwCVxcaW8hwaQ25er+ETEgWU9
>          DK9Q==
> X-Gm-Message-State: ALoCoQmHzfdGMpqQ7DTvrzz4hpObpdipXgf2lGK+1cbRTSUyoaRE9sz7r32vzDU4Dsf3MuyWtioe7lnz0x3W8va3BaN2qtW/4g1vpApNOlp2FOxktOlZoZfYLfTcDRAkcCTofZ7ZrhLE
> MIME-Version: 1.0
> X-Received: by 10.66.159.234 with SMTP id xf10mr3984291pab.139.1383746298406;
>  Wed, 06 Nov 2013 05:58:18 -0800 (PST)
> Received: by 10.68.193.138 with HTTP; Wed, 6 Nov 2013 05:58:18 -0800 (PST)
> In-Reply-To: <20131022181141.3f567273@skate>
> References: <CAFJTrDtznkpwi76yyEKYvjuo+XV34ky9AOe8Qfa5wm-uHDJT6A@mail.gmail.com>
>         <20131021174339.GA27284@localhost>
>         <20131021184219.GA24520@titan.lakedaemon.net>
>         <20131022152950.40171b36@skate>
>         <CAFJTrDtKw0ANh55Y6xQtFzGtvmZOJ-ZC6cFuKV62L0tmmhT3uA@mail.gmail.com>
>         <20131022181141.3f567273@skate>
> Date: Wed, 6 Nov 2013 13:58:18 +0000
> Message-ID: <CAFJTrDsaq-NjLhcwHBuN1Q_zu-Q-yJkWLMUER1zVzc1=AFNM=Q@mail.gmail.com>
> Subject: Re: Armada XP Internal registers
> From: Matthew Minter <matthew_minter@xyratex.com>
> To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
>         Jason Cooper <jason@lakedaemon.net>, Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
>         linux-arm-kernel at lists.infradead.org
> Content-Type: multipart/alternative; boundary=047d7b86e7729390ac04ea828a5b
>
> Hi Everyone,
>
> I am sorry for the exceedingly long delay before replying, I have had a
> number of unrelated problems which have prevented me from working on this
> issue.
>
> The version of u-boot which caused this issue was Marvell's Q2-2013
> release. I used this with a 3.12 rc1 and a 3.12 rc3 kernel, both receiving
> the errors I have mentioned above. I have ensured my low level debugging
> configuration is correct, it is indeed mapped correctly to the new register
> range and I do not believe this to be the problem, particularly as it
> crashes well after the early printk has begun giving output.
>
> Unfortunately I cannot find the log file from the kernel at this stage as
> it appears to have been filled and overwritten, I however did look into
> this further and Marvell have (since when I raised the problem) given me a
> patched u-boot which is no longer causing the issue (the patch seems to be
> dated mid October 2013), unfortunately I cant post the change log of the
> patch but it does appear the problem was caused by a buggy u-boot release
> (or at least that it is fixed with the patched version). I have since
> tested the new version with kernels 3.12 rc3 to 3.12 rc6 and none of them
> have any issues with booting. Here is a full diff of the change I made to
> the device tree file (dont mind the bogus timestamps)
>
> --- arch/arm/boot/dts/armada-xp-gp.dts.old    2013-11-06 13:39:17.440000000
> +0000
> +++ arch/arm/boot/dts/armada-xp-gp.dts    2013-11-05 17:32:16.160001348
> +0000
> @@ -39,7 +39,7 @@
>      };
>
>      soc {
> -        ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
> +        ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
>                MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>                MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
>
> I think the issue therefore may not be a kernel issue after all and should
> likely not be worried about. However on a related matter, I had thought the
> kernel was supposed to have some kind of detection for the register
>
> ----- Message truncated -----
>

-- 


------------------------------
For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com

------------------------------

Armada XP Internal registers

[Thomas Petazzoni]

Dear Matthew Minter,

On Wed, 6 Nov 2013 13:58:18 +0000, Matthew Minter wrote:

> I am sorry for the exceedingly long delay before replying, I have had
> a number of unrelated problems which have prevented me from working
> on this issue.
> 
> The version of u-boot which caused this issue was Marvell's Q2-2013
> release. I used this with a 3.12 rc1 and a 3.12 rc3 kernel, both
> receiving the errors I have mentioned above. I have ensured my low
> level debugging configuration is correct, it is indeed mapped
> correctly to the new register range and I do not believe this to be
> the problem, particularly as it crashes well after the early printk
> has begun giving output.
> 
> Unfortunately I cannot find the log file from the kernel at this
> stage as it appears to have been filled and overwritten, I however
> did look into this further and Marvell have (since when I raised the
> problem) given me a patched u-boot which is no longer causing the
> issue (the patch seems to be dated mid October 2013), unfortunately I
> cant post the change log of the patch but it does appear the problem
> was caused by a buggy u-boot release (or at least that it is fixed
> with the patched version). I have since tested the new version with
> kernels 3.12 rc3 to 3.12 rc6 and none of them have any issues with
> booting. Here is a full diff of the change I made to the device tree
> file (dont mind the bogus timestamps)
> 
> --- arch/arm/boot/dts/armada-xp-gp.dts.old    2013-11-06
> 13:39:17.440000000 +0000
> +++ arch/arm/boot/dts/armada-xp-gp.dts    2013-11-05
> 17:32:16.160001348 +0000
> @@ -39,7 +39,7 @@
>      };
> 
>      soc {
> -        ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
> +        ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000

Yeah, classical old bootloaders vs. new bootloaders problem.

>                MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>                MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
> 
> I think the issue therefore may not be a kernel issue after all and
> should likely not be worried about. However on a related matter, I
> had thought the kernel was supposed to have some kind of detection
> for the register location using cp15? Why does the device tree
> describe the register address staticly if this is the case?

There is no such thing as a CP15 register that contains the base
address of the internal registers.

The base address of the internal registers is defined through a
register, which is itself part of the internal registers. So to set or
retrieve the base address of the internal registers, you have to know
what is the base address of the internal registers :-)

We've gone through /huge/ discussions about this on the list. I did
propose to use a spare CP15 bit somewhere to let the bootloader
indicate that the internal registers have been remapped to 0xf1, or
have been left at 0xd0. But this has been rejected by the ARM kernel
people, who considered it to be an ugly extension of the boot protocol
(i.e the interface between the bootloader and the kernel), which is
indeed a valid argument.

> Ultimately I think the specific errors I was getting (along with the
> exact error being variable dependant on seemingly random factors)
> made the specific errors a red herring and the problem was due to a
> faulty initialisation by the bootloader. However if there is any
> other information I can give or if anyone is interested I may be able
> to find out more.

What were the errors? From a quick read of the e-mail thread, I only
seem to see discussion about 0xd0 vs. 0xf1, which is a well known
problem.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Armada XP Internal registers

[Thomas Petazzoni]

Dear Matthew Minter,

On Wed, 6 Nov 2013 14:31:49 +0000, Matthew Minter wrote:

> Thanks for the clarification regarding this CP15 bit, I saw various
> documentation mentioning it and had assumed it had been implemented. I
> understand the issue now and also understand why there is a difference
> between the easiest solution and the most elegant.

I believe the CP15 bit solution might have showed up in some Marvell
U-Boot versions, since it was part of our plan to use that, but our
plan failed :)

> However now I understand the issue that is no longer a problem, the
> other half of my email was regarding issues I was having booting using
> a certain, seemingly briefly available version of Marvell's Q2 2013
> u-boot which was causing the kernel to read spurious interrupts and a
> particular "Unhandled fault: external abort on non-linefetch" problem
> which would cause the kernel to panic during the boot process, usually
> during PCI initialisation. However it seems that the problem was due
> to a bug in the version of uboot and has now been patched by Marvell
> and was not an issue with the kernel after all. This at least seems to
> be the case as the patched u-boot allows the previously problematic
> kernel's to boot fine.
> 
> Ultimately I think it is a non issue as it was not (to my
> understanding) a kernel issue in the first place, sorry.

Sure, no problem, thanks for getting back to us about this!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com