From: Sudeep Holla <sudeep.holla@arm.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
James Morse <james.morse@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: ARM Juno r1 + CONFIG_PROVE_LOCKING=y => boot failure
Date: Fri, 11 Oct 2019 14:43:54 +0100 [thread overview]
Message-ID: <20191011134354.GA31516@bogus> (raw)
In-Reply-To: <0b02b15f-38be-7a63-14cc-eabd288782eb@samsung.com>
On Fri, Oct 11, 2019 at 03:15:32PM +0200, Marek Szyprowski wrote:
> Hi Sudeep
>
> On 11.10.2019 15:10, Sudeep Holla wrote:
> > On Fri, Oct 11, 2019 at 03:02:42PM +0200, Marek Szyprowski wrote:
> >> Hi James,
> >>
> >> On 11.10.2019 12:38, James Morse wrote:
> >>> Hi guys,
> >>>
> >>> On 11/10/2019 11:05, Sudeep Holla wrote:
> >>>> On Fri, Oct 11, 2019 at 11:26:04AM +0200, Marek Szyprowski wrote:
> >>>>> Recently I've got access to ARM Juno R1 board and did some tests with
> >>>>> current mainline kernel on it. I'm a bit surprised that enabling
> >>>>> CONFIG_PROVE_LOCKING causes a boot failure on this board. After enabling
> >>>>> this Kconfig option, I get no single message from the kernel, although I
> >>>>> have earlycon enabled.
> >>>> I don't have Juno R1 but I tried defconfig + CONFIG_PROVE_LOCKING and
> >>>> it boots fine.
> >>> I just tried this on my r1, v5.4-rc1 with this configuration worked just fine.
> >>>
> >>> My cmdline is:
> >>> | root=/dev/sda6 loglevel=9 earlycon=pl011,0x7ff80000 hugepagesz=2M hugepages=512
> >>> | crashkernel=1G console=ttyAMA0 resume=/dev/sda2 no_console_suspend efi=debug
> >>>
> >> That is a bit strange. Here is a boot log from v5.4-rc1 with pure
> >> defconfig: https://paste.debian.net/1105851/
> >>
> > I see from the boot log that both Image.gz and dtb being loaded at the
> > same address 0x82000000, will u-boot uncompress it elsewhere after loading
> > it ? Just for my understanding.
>
> tftp downloads Image.gz to 0x82000000, then decompress it to
> $kernel_addr to save transfer time
>
> my bootcmd is:
>
> tftp ${fdt_addr} juno/Image.gz; unzip ${fdt_addr} ${kernel_addr}; tftp
> ${fdt_addr} juno/juno-r1.dtb; booti ${kernel_addr} - ${fdt_addr};
>
Thanks for the info. I got hold of R1 board(not the one James has ;))
and it works fine on that too.
Further, with reference to the commit you mentioned make sure defconfig
works with that as it's a commit in the middle of merge window.
I am using gcc7 and I noticed yours is gcc6 not sure if that makes any
difference. Just listing the differences.
I will see if I can grab the exact linaro binaries.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: James Morse <james.morse@arm.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Will Deacon <will@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: ARM Juno r1 + CONFIG_PROVE_LOCKING=y => boot failure
Date: Fri, 11 Oct 2019 14:43:54 +0100 [thread overview]
Message-ID: <20191011134354.GA31516@bogus> (raw)
In-Reply-To: <0b02b15f-38be-7a63-14cc-eabd288782eb@samsung.com>
On Fri, Oct 11, 2019 at 03:15:32PM +0200, Marek Szyprowski wrote:
> Hi Sudeep
>
> On 11.10.2019 15:10, Sudeep Holla wrote:
> > On Fri, Oct 11, 2019 at 03:02:42PM +0200, Marek Szyprowski wrote:
> >> Hi James,
> >>
> >> On 11.10.2019 12:38, James Morse wrote:
> >>> Hi guys,
> >>>
> >>> On 11/10/2019 11:05, Sudeep Holla wrote:
> >>>> On Fri, Oct 11, 2019 at 11:26:04AM +0200, Marek Szyprowski wrote:
> >>>>> Recently I've got access to ARM Juno R1 board and did some tests with
> >>>>> current mainline kernel on it. I'm a bit surprised that enabling
> >>>>> CONFIG_PROVE_LOCKING causes a boot failure on this board. After enabling
> >>>>> this Kconfig option, I get no single message from the kernel, although I
> >>>>> have earlycon enabled.
> >>>> I don't have Juno R1 but I tried defconfig + CONFIG_PROVE_LOCKING and
> >>>> it boots fine.
> >>> I just tried this on my r1, v5.4-rc1 with this configuration worked just fine.
> >>>
> >>> My cmdline is:
> >>> | root=/dev/sda6 loglevel=9 earlycon=pl011,0x7ff80000 hugepagesz=2M hugepages=512
> >>> | crashkernel=1G console=ttyAMA0 resume=/dev/sda2 no_console_suspend efi=debug
> >>>
> >> That is a bit strange. Here is a boot log from v5.4-rc1 with pure
> >> defconfig: https://paste.debian.net/1105851/
> >>
> > I see from the boot log that both Image.gz and dtb being loaded at the
> > same address 0x82000000, will u-boot uncompress it elsewhere after loading
> > it ? Just for my understanding.
>
> tftp downloads Image.gz to 0x82000000, then decompress it to
> $kernel_addr to save transfer time
>
> my bootcmd is:
>
> tftp ${fdt_addr} juno/Image.gz; unzip ${fdt_addr} ${kernel_addr}; tftp
> ${fdt_addr} juno/juno-r1.dtb; booti ${kernel_addr} - ${fdt_addr};
>
Thanks for the info. I got hold of R1 board(not the one James has ;))
and it works fine on that too.
Further, with reference to the commit you mentioned make sure defconfig
works with that as it's a commit in the middle of merge window.
I am using gcc7 and I noticed yours is gcc6 not sure if that makes any
difference. Just listing the differences.
I will see if I can grab the exact linaro binaries.
--
Regards,
Sudeep
next prev parent reply other threads:[~2019-10-11 13:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20191011092604eucas1p1ca11ab9c4c7508776914b0eb4f35e69b@eucas1p1.samsung.com>
2019-10-11 9:26 ` ARM Juno r1 + CONFIG_PROVE_LOCKING=y => boot failure Marek Szyprowski
2019-10-11 10:05 ` Sudeep Holla
2019-10-11 10:05 ` Sudeep Holla
2019-10-11 10:21 ` Marek Szyprowski
2019-10-11 10:21 ` Marek Szyprowski
2019-10-11 10:38 ` James Morse
2019-10-11 10:38 ` James Morse
2019-10-11 10:59 ` Sudeep Holla
2019-10-11 10:59 ` Sudeep Holla
2019-10-11 13:02 ` Marek Szyprowski
2019-10-11 13:02 ` Marek Szyprowski
2019-10-11 13:10 ` Sudeep Holla
2019-10-11 13:10 ` Sudeep Holla
2019-10-11 13:15 ` Marek Szyprowski
2019-10-11 13:15 ` Marek Szyprowski
2019-10-11 13:43 ` Sudeep Holla [this message]
2019-10-11 13:43 ` Sudeep Holla
2019-10-11 14:42 ` Sudeep Holla
2019-10-11 14:42 ` Sudeep Holla
2019-10-14 9:02 ` Marek Szyprowski
2019-10-14 9:02 ` Marek Szyprowski
2019-10-14 10:16 ` James Morse
2019-10-14 10:16 ` James Morse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191011134354.GA31516@bogus \
--to=sudeep.holla@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=m.szyprowski@samsung.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.