Re: Re:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 23, 2019 at 12:19:13PM +0000, Tristan Bastian wrote:
> 
> Thierry Reding – Wed, 23. January 2019 13:04
> > On Tue, Jan 22, 2019 at 07:34:39PM +0000, Tristan Bastian wrote:
> > > 
> > > 
> > > 
> > > Thierry Reding – Tue, 22. January 2019 17:13
> > > > On Tue, Jan 22, 2019 at 03:23:51PM +0000, Tristan Bastian wrote:
> > > > > Hello, 
> > > > > 
> > > > > since mainline kernel 4.19 LPAE is no longer working for me and some
> > others
> > > > on tegra124-nyan-big.
> > > > > Is this a known problem with a fix already available?
> > > > > 
> > > > > The defconfig to compile the kernel can be found here: 
> > > > github.com/reey/PKGBUILDs/blob/master/core/linux-nyan/nyan-big_defconfig
> > > > > Basically we are only getting 2 GB instead of 4 GB of memory.
> > > > > Kernel 4.18 still gives us 4 GB.
> > > > > Both kernels are configured with CONFIG_ARM_LPAE=y.
> > > > > All newer kernel versions also have this bug..
> > > > 
> > > > Looking at the git log, I can only find one possibly suspicious change:
> > > > 
> > > > commit 482997699ef038af7553399d49b7ba74c3301424
> > > > Author: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> > > > Date: Mon Jul 9 18:05:17 2018 +0200
> > > > 
> > > > ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory
> > > > 
> > > > Add a generic /memory node in each Tegra DTSI (with empty reg property,
> > > > to be overidden by each DTS) and set proper unit address for /memory
> > > > nodes to fix the DTC warnings:
> > > > 
> > > > arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
> > > > /memory: node has a reg or ranges property, but no unit name
> > > > 
> > > > The DTB after the change is the same as before except adding
> > > > unit-address to /memory node.
> > > > 
> > > > Signed-off-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> > > > Reviewed-by: Stefan Agner <stefan@xxxxxxxx>
> > > > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
> > > > 
> > > > I suppose this could result in the bootloader failing to find the memory
> > > > node when trying to patch up the memory banks. It looks like U-Boot
> > > > handles this properly by ignoring the unit-address when looking up nodes
> > > > by name (without unit-address), but I suspect that coreboot may not be
> > > > doing this. I'm assuming that coreboot is what you're using as
> > > > bootloader?
> > > > 
> > > > If coreboot behaves similarly to U-Boot, it'll create a new node if it
> > > > can't find a matching one, so you may be able to inspect the device tree
> > > > that was passed to the kernel (/sys/firmware/fdt should have the binary
> > > > and /sys/firmware/devicetree should have a directory tree representation
> > > > of the device tree).
> > > > 
> > > > Thierry
> > > 
> > > Hi Thierry,
> > > 
> > > I'm using coreboot.
> > > But what I can also tell is, that when you use U-Boot chainloaded to
> > coreboot, LPAE is also not working with older kernel revisions like 4.18.
> > > I only found a single memory entry in /sys/firmware/devicetree/
> > "memory@80000000"...
> > > 
> > > BTW: @Thierry, I'm reverting this patch: patchwork.kernel.org/patch/9516105/ 
> > because otherwise I'm getting a blank screen on bootup. Is there any fix for
> > that going upstream?
> > 
> > Yes, there was some work to get that fixed, but it keeps getting stuck.
> > I'll resume the old threads to see if we can gain some traction. Can I
> > add you on Cc for testing any patch related to that?
> > 
> > Thierry
> 
> Sure, just add me.
> My email client somehow removed the subject of these emails..
> I've sent another mail with the original subject, where I wrote: 
> 
> > I have to correct myself.
> > I found two memory entries in /sys/firmware/devicetree/base/.
> > One called "memory@80000000" and the other one just "memory".
> Just making sure, that you've got that.

It looks as if your email client also breaks threading. I see these
emails from you appear randomly in my mailbox rather than threaded with
the earlier messages.

> Should I try a kernel, which reverted "ARM: tegra: Fix
> unit_address_vs_reg DTC warnings for /memory" to make sure that this
> is causing the issue?

I replied to that email separately and suggested pretty much that. I'm
fairly confident that that will restore > 2 GiB for you, so we just need
to figure out what to do about it. Just reverting the patch will
reintroduce the warning that it silenced.

Thierry

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux