| Message ID | 1378817379-8238-2-git-send-email-lee.jones@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones <lee.jones@linaro.org> wrote: > Turns out that they're actually not required and the driver probes just > fine without them. The ID is incorrect at the moment anyway. They actually > currently specify the stn8815. > > Signed-off-by: Lee Jones <lee.jones@linaro.org> How did you test this patch? What hardware did you boot it on and with what config? Thanks! -Olof
> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones <lee.jones@linaro.org> wrote: > > Turns out that they're actually not required and the driver probes just > > fine without them. The ID is incorrect at the moment anyway. They actually > > currently specify the stn8815. > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > How did you test this patch? What hardware did you boot it on and with > what config? Snowball, u8500_defconfig. Why? Don't you have the same result with yours?
[pruning out the iio list/people] On Tue, Sep 10, 2013 at 8:30 AM, Lee Jones <lee.jones@linaro.org> wrote: >> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones <lee.jones@linaro.org> wrote: >> > Turns out that they're actually not required and the driver probes just >> > fine without them. The ID is incorrect at the moment anyway. They actually >> > currently specify the stn8815. >> > >> > Signed-off-by: Lee Jones <lee.jones@linaro.org> >> >> How did you test this patch? What hardware did you boot it on and with >> what config? > > Snowball, u8500_defconfig. > > Why? Don't you have the same result with yours? I have a very weird experience with snowball right now. I noticed this yesterday when I decided to look at why multi_v7_defconfig doesn't boot on it: * u8500_defconfig doesn't boot as a DT kernel, since the machine ID is still enabled. If I disable the machine ID, it doesn't boot. * Same for multi_v7_defconfig, since that is only DT: It doesn't boot. Unfortunately I can't get to my home network right now to double-check boot logs to see if this has changed behavior recently, I'll have to do that later today. It'd be interesting to hear if you have the same experience w.r.t. DT on u8500_defconfig though. -Olof
On Tue, Sep 10, 2013 at 6:57 PM, Olof Johansson <olof@lixom.net> wrote: > I have a very weird experience with snowball right now. I noticed this > yesterday when I decided to look at why multi_v7_defconfig doesn't > boot on it: > > * u8500_defconfig doesn't boot as a DT kernel, since the machine ID is > still enabled. If I disable the machine ID, it doesn't boot. > * Same for multi_v7_defconfig, since that is only DT: It doesn't boot. Weird, yeah there is something wrong on Torvalds' HEAD, with earlyprint it says: Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported processor variant (0x412fc091). This comes from arch/arm/kernel/head-common.S I'm trying to bisect and find out what is causing this... Yours, Linus Walleij
On Tue, 10 Sep 2013, Olof Johansson wrote: > [pruning out the iio list/people] > > On Tue, Sep 10, 2013 at 8:30 AM, Lee Jones <lee.jones@linaro.org> wrote: > >> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones <lee.jones@linaro.org> wrote: > >> > Turns out that they're actually not required and the driver probes just > >> > fine without them. The ID is incorrect at the moment anyway. They actually > >> > currently specify the stn8815. > >> > > >> > Signed-off-by: Lee Jones <lee.jones@linaro.org> > >> > >> How did you test this patch? What hardware did you boot it on and with > >> what config? > > > > Snowball, u8500_defconfig. > > > > Why? Don't you have the same result with yours? > > I have a very weird experience with snowball right now. I noticed this > yesterday when I decided to look at why multi_v7_defconfig doesn't > boot on it: > > * u8500_defconfig doesn't boot as a DT kernel, since the machine ID is > still enabled. If I disable the machine ID, it doesn't boot. > * Same for multi_v7_defconfig, since that is only DT: It doesn't boot. I'm not entirely sure what you mean by this, as I have Snowball booting as a Device Tree only platform: http://www.spinics.net/lists/kernel/msg1590759.html The Machine ID should be all F's for DT I think. > Unfortunately I can't get to my home network right now to double-check > boot logs to see if this has changed behavior recently, I'll have to > do that later today. It'd be interesting to hear if you have the same > experience w.r.t. DT on u8500_defconfig though. I just changed SNOWBALL's machine ID to 9999 and it still boots just fine with DT (ATAGs boot hangs). So what did you do? Can you send me a patch of what you did, so I might reproduce your build please?
On Wed, 11 Sep 2013, Linus Walleij wrote: > On Tue, Sep 10, 2013 at 6:57 PM, Olof Johansson <olof@lixom.net> wrote: > > > I have a very weird experience with snowball right now. I noticed this > > yesterday when I decided to look at why multi_v7_defconfig doesn't > > boot on it: > > > > * u8500_defconfig doesn't boot as a DT kernel, since the machine ID is > > still enabled. If I disable the machine ID, it doesn't boot. > > * Same for multi_v7_defconfig, since that is only DT: It doesn't boot. > > Weird, yeah there is something wrong on Torvalds' HEAD, with > earlyprint it says: > > Uncompressing Linux... done, booting the kernel. > Error: unrecognized/unsupported processor variant (0x412fc091). > This comes from arch/arm/kernel/head-common.S > > I'm trying to bisect and find out what is causing this... Ah nice. Keep us informed of any progress.
On Wed, Sep 11, 2013 at 10:19 AM, Lee Jones <lee.jones@linaro.org> wrote: > On Wed, 11 Sep 2013, Linus Walleij wrote: > >> Weird, yeah there is something wrong on Torvalds' HEAD, with >> earlyprint it says: >> >> Uncompressing Linux... done, booting the kernel. >> Error: unrecognized/unsupported processor variant (0x412fc091). >> This comes from arch/arm/kernel/head-common.S >> >> I'm trying to bisect and find out what is causing this... > > Ah nice. Keep us informed of any progress. No it was something transient, after a clean rebuild it boots just fine. :-/ I'll see if I can boot the same uImage on the Snowball too. Linus Walleij
On Wed, Sep 11, 2013 at 11:39 AM, Lee Jones <lee.jones@linaro.org> wrote: > On 11 Sep 2013 10:33, "Linus Walleij" <linus.walleij@linaro.org> wrote: >> No it was something transient, after a clean rebuild it boots >> just fine. :-/ >> >> I'll see if I can boot the same uImage on the Snowball too. Yeah Snowball boots the same DT image with just some random dmesg noise from Torvalds HEAD: U8500 $ mmc rescan 1 ; fat load mmc 1 0x0 /uImage ; bootm 0x0 Partition info retrieved Reading /uImage 8997342 bytes read ## Booting kernel from Legacy Image at 00000000 ... Image Name: Ux500 Device Tree kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 8997278 Bytes = 8.6 MB Load Address: 00008000 Entry Point: 00008000 Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x300 Linux version 3.11.0-09031-ga22a0fd (linus@localhost.localdomain) (gcc version 4.8.2 20130805 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.08 - Linaro GCC 2013.08) ) #48 SMP PREEMPT Wed Sep 11 11:14:36 CEST 2013 CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: ST-Ericsson Ux5x0 platform (Device Tree Support), model: ST-Ericsson HREF (v60+) platform with Device Tree Only cachepolicy=writeback supported on ARMv6 and later Memory policy: ECC disabled, Data cache writealloc DB8500 v2.1 [0x008500b1] (...) I don't know what is the problem with Olof's machine :-/ Olof do you want a copy of my uImage? Yours, Linus Walleij
On Wed, Sep 11, 2013 at 4:13 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Wed, Sep 11, 2013 at 11:39 AM, Lee Jones <lee.jones@linaro.org> wrote: >> On 11 Sep 2013 10:33, "Linus Walleij" <linus.walleij@linaro.org> wrote: > >>> No it was something transient, after a clean rebuild it boots >>> just fine. :-/ >>> >>> I'll see if I can boot the same uImage on the Snowball too. > > Yeah Snowball boots the same DT image with just some random > dmesg noise from Torvalds HEAD: > > U8500 $ mmc rescan 1 ; fat load mmc 1 0x0 /uImage ; bootm 0x0 > Partition info retrieved > Reading /uImage > > 8997342 bytes read > ## Booting kernel from Legacy Image at 00000000 ... > Image Name: Ux500 Device Tree kernel > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 8997278 Bytes = 8.6 MB > Load Address: 00008000 > Entry Point: 00008000 > Loading Kernel Image ... OK > OK > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > Booting Linux on physical CPU 0x300 > Linux version 3.11.0-09031-ga22a0fd (linus@localhost.localdomain) (gcc > version 4.8.2 20130805 (prerelease) (crosstool-NG > linaro-1.13.1-4.8-2013.08 - Linaro GCC 2013.08) ) #48 SMP PREEMPT Wed > Sep 11 11:14:36 CEST 2013 > CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > Machine: ST-Ericsson Ux5x0 platform (Device Tree Support), model: > ST-Ericsson HREF (v60+) platform with Device Tree > Only cachepolicy=writeback supported on ARMv6 and later > Memory policy: ECC disabled, Data cache writealloc > DB8500 v2.1 [0x008500b1] > (...) > > I don't know what is the problem with Olof's machine :-/ Oh! Well, to start with apparantly u8500_defconfig doesn't have APPENDED_DTB enabled, which explains some of the confusion here. With that fixed (and the appropriate options to get the bootargs from the atags), I get as far as console probing where output stops, if I have DEBUG_LL on. With it disabled I get all the way up. Not sure what was going on earlier here. Maybe just as in your case it was a matter of cleaning out and starting fresh. multi_v7_defconfig still doesn't boot though, but the failure seems to be lower level than any of the others, no output with DEBUG_LL on. -Olof
On Wed, Sep 11, 2013 at 10:36 PM, Olof Johansson <olof@lixom.net> wrote: > [Me] >> I don't know what is the problem with Olof's machine :-/ > > Oh! Well, to start with apparantly u8500_defconfig doesn't have > APPENDED_DTB enabled, which explains some of the confusion here. Oh. Well honestly I think we will never be able to rewrite the U8500 bootloaders, so maybe I should just send a patch adding this to the defconfig by default. > With that fixed (and the appropriate options to get the bootargs from > the atags), I get as far as console probing where output stops, if I > have DEBUG_LL on. With it disabled I get all the way up. Yeah somewhere the bit-banging from the LL-prints that just hammer the hardware start conflicting with the kernel control over the same port. I guess it's the same for all users of the PL011. > Not sure what was going on earlier here. Maybe just as in your case it > was a matter of cleaning out and starting fresh. Yeah, it's scary :-/ > multi_v7_defconfig still doesn't boot though, but the failure seems to > be lower level than any of the others, no output with DEBUG_LL on. Probably the usual case where one system is screwing up for another system. We'll need to look into this. Yours, Linus Walleij
On Thu, Sep 12, 2013 at 02:23:48PM +0200, Linus Walleij wrote: > Yeah somewhere the bit-banging from the LL-prints that just > hammer the hardware start conflicting with the kernel control > over the same port. I guess it's the same for all users of the > PL011. That shouldn't happen, unless the port becomes disabled (eg, you're not using the LL-debug port as your console, and its then placed into a low power mode.) Again, let me re-interate what LL-debug is for: it's there to assist getting the early boot up and running. Once the early boot is working, it should *not* be used.
diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi b/arch/arm/boot/dts/ste-dbx5x0.dtsi index 1c1091e..0c1338e 100644 --- a/arch/arm/boot/dts/ste-dbx5x0.dtsi +++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi @@ -559,7 +559,6 @@ compatible = "stericsson,db8500-i2c", "st,nomadik-i2c", "arm,primecell"; reg = <0x80004000 0x1000>; interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>; - arm,primecell-periphid = <0x180024>; #address-cells = <1>; #size-cells = <0>; @@ -572,7 +571,6 @@ compatible = "stericsson,db8500-i2c", "st,nomadik-i2c", "arm,primecell"; reg = <0x80122000 0x1000>; interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>; - arm,primecell-periphid = <0x180024>; #address-cells = <1>; #size-cells = <0>; @@ -585,7 +583,6 @@ compatible = "stericsson,db8500-i2c", "st,nomadik-i2c", "arm,primecell"; reg = <0x80128000 0x1000>; interrupts = <0 55 IRQ_TYPE_LEVEL_HIGH>; - arm,primecell-periphid = <0x180024>; #address-cells = <1>; #size-cells = <0>; @@ -598,7 +595,6 @@ compatible = "stericsson,db8500-i2c", "st,nomadik-i2c", "arm,primecell"; reg = <0x80110000 0x1000>; interrupts = <0 12 IRQ_TYPE_LEVEL_HIGH>; - arm,primecell-periphid = <0x180024>; #address-cells = <1>; #size-cells = <0>; @@ -611,7 +607,6 @@ compatible = "stericsson,db8500-i2c", "st,nomadik-i2c", "arm,primecell"; reg = <0x8012a000 0x1000>; interrupts = <0 51 IRQ_TYPE_LEVEL_HIGH>; - arm,primecell-periphid = <0x180024>; #address-cells = <1>; #size-cells = <0>;
Turns out that they're actually not required and the driver probes just fine without them. The ID is incorrect at the moment anyway. They actually currently specify the stn8815. Signed-off-by: Lee Jones <lee.jones@linaro.org> --- arch/arm/boot/dts/ste-dbx5x0.dtsi | 5 ----- 1 file changed, 5 deletions(-)