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. 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? Tristan
