Hi, I experimented a little to make the Pyra run with standard Letux with 4GB RAM.
So far I did the following: * check that U-Boot has hypervisor mode enabled * compile kernel with lpae enabled * modify the makesd script to make a bootable SD card using the lpae kernel/dt/modules
But I still have only 2GB RAM. In U-boot and in Kernel.
What else has to be modified? Device Tree? Boot Script?
BR, Nikolaus
If you use my u-boot (https://github.com/mvduin/u-boot) with CONFIG_DUAL_RANK_DDR3 set then it will configure ram to use both ranks, interleaved, hence both will get exercised then regardless of how much memory the kernel is configured to use, and regardless of whether it is an LPAE kernel or not.
The main patch for this is: https://github.com/mvduin/u-boot/commit/06e3cb0f3731763372ca437ac0775e040a7d...
This should suffice to test the memory itself.
Making all 4GB available to the kernel right now still requires an LPAE kernel and telling it about the memory available via kernel parameters (I still need to check how to tell it via DT but classified that as non-urgent): mem=2032M@0x80000000 mem=2048M@0x200000000 or, if you're in an experimental mood: mem=2032M@0x80000000 mem=2064M@0x2FF000000 to get back the 16M stolen from the end of lowmem.
Any issues that arise as the result of this are presumably purely kernel issues.
Matthijs
Hi Matthijs,
Am 23.04.2017 um 03:12 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
If you use my u-boot (https://github.com/mvduin/u-boot) with CONFIG_DUAL_RANK_DDR3 set then it will configure ram to use both ranks, interleaved, hence both will get exercised then regardless of how much memory the kernel is configured to use, and regardless of whether it is an LPAE kernel or not.
The main patch for this is: https://github.com/mvduin/u-boot/commit/06e3cb0f3731763372ca437ac0775e040a7d...
This should suffice to test the memory itself.
Ok! Fine.
Making all 4GB available to the kernel right now still requires an LPAE kernel and telling it about the memory available via kernel parameters (I still need to check how to tell it via DT but classified that as non-urgent): mem=2032M@0x80000000 mem=2048M@0x200000000 or, if you're in an experimental mood: mem=2032M@0x80000000 mem=2064M@0x2FF000000 to get back the 16M stolen from the end of lowmem.
a simple solution could be to add it to CONFIG_CMDLINE for letux_lpae_defconfig. Basically U-Boot patches the memory {} entry in the FDT which is passed to the kernel. It already does that for different memory sizes (e.g. on OMAP3).
So if U-Boot detects and knows the correct memory dimensions it should already pass it to the kernel. But that may be broken. This is something I can look into.
Another (small) issue is that U-Boot seems not to detect the memory size automatically. At least with your patch above I get memory failed messages on 2GB boards while a 4GB board works and shows 2GB.
In the worst case we need two different U-Boot builds (e.g. a 2G and a 4GB config).
Any issues that arise as the result of this are presumably purely kernel issues.
Matthijs
BR and thanks, Nikolaus
Am 23.04.2017 um 11:27 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Matthijs,
Am 23.04.2017 um 03:12 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
If you use my u-boot (https://github.com/mvduin/u-boot) with CONFIG_DUAL_RANK_DDR3 set then it will configure ram to use both ranks, interleaved, hence both will get exercised then regardless of how much memory the kernel is configured to use, and regardless of whether it is an LPAE kernel or not.
The main patch for this is: https://github.com/mvduin/u-boot/commit/06e3cb0f3731763372ca437ac0775e040a7d...
This should suffice to test the memory itself.
Ok! Fine.
Making all 4GB available to the kernel right now still requires an LPAE kernel and telling it about the memory available via kernel parameters (I still need to check how to tell it via DT but classified that as non-urgent): mem=2032M@0x80000000 mem=2048M@0x200000000 or, if you're in an experimental mood: mem=2032M@0x80000000 mem=2064M@0x2FF000000 to get back the 16M stolen from the end of lowmem.
a simple solution could be to add it to CONFIG_CMDLINE for letux_lpae_defconfig. Basically U-Boot patches the memory {} entry in the FDT which is passed to the kernel. It already does that for different memory sizes (e.g. on OMAP3).
So if U-Boot detects and knows the correct memory dimensions it should already pass it to the kernel. But that may be broken. This is something I can look into.
Another (small) issue is that U-Boot seems not to detect the memory size automatically. At least with your patch above I get memory failed messages on 2GB boards while a 4GB board works and shows 2GB.
In the worst case we need two different U-Boot builds (e.g. a 2G and a 4GB config).
Any issues that arise as the result of this are presumably purely kernel issues.
No issues seen so far (well, testing 5 minutes is not enough):
Debian GNU/Linux 8 letux console
letux login: root Password: Last login: Sat Jan 1 00:23:28 UTC 2000 on console Linux letux 4.11.0-rc7-letux-lpae+ #1007 SMP PREEMPT Sun Apr 23 10:02:20 CEST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@letux:~# cat /proc/meminfo MemTotal: 4111824 kB MemFree: 3782000 kB MemAvailable: 3989228 kB Buffers: 12444 kB Cached: 255280 kB SwapCached: 0 kB Active: 152096 kB Inactive: 140064 kB Active(anon): 24604 kB Inactive(anon): 30732 kB Active(file): 127492 kB Inactive(file): 109332 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 3388416 kB HighFree: 3134768 kB LowTotal: 723408 kB LowFree: 647232 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 220 kB Writeback: 0 kB AnonPages: 24432 kB Mapped: 24708 kB Shmem: 30904 kB Slab: 22996 kB SReclaimable: 11932 kB SUnreclaim: 11064 kB KernelStack: 1624 kB PageTables: 784 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2055912 kB Committed_AS: 180568 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 16384 kB CmaFree: 13696 kB root@letux:~#
BR and thanks!!!
Nikolaus
parameters (I still need to check how to tell it via DT but classified that as non-urgent):
seems to be done by
common/fdt_support.c: fdt_fixup_memory_banks()
That function has u64 parameter for start[] and size[]. Maybe U-Boot configures our 4GB RAM with 2 banks but still assumes each one is 1GB size.
Now, the boring part begins: going through code to find out how the parameters are set by the board file...
BR, Nikolaus
Am 23.04.2017 um 15:49 schrieb H. Nikolaus Schaller hns@goldelico.com:
parameters (I still need to check how to tell it via DT but classified that as non-urgent):
seems to be done by
common/fdt_support.c: fdt_fixup_memory_banks()
That function has u64 parameter for start[] and size[]. Maybe U-Boot configures our 4GB RAM with 2 banks but still assumes each one is 1GB size.
Now, the boring part begins: going through code to find out how the parameters are set by the board file...
I think I have it running. Cleaned up patch is coming.
The only ugly issue is that I have no idea if we can auto-detect the RAM type / size. And we forgot to assign different CPU board version resistors.
So it either works or the other u-boot.img has to be installed on the SD card.
This makes swapping bootable SD cards between both variants impossible. Which is annoying since(I always forget to write on them what they are good for...
BR, Nikolaus
Am 23.04.2017 um 21:42 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 23.04.2017 um 15:49 schrieb H. Nikolaus Schaller hns@goldelico.com:
parameters (I still need to check how to tell it via DT but classified that as non-urgent):
seems to be done by
common/fdt_support.c: fdt_fixup_memory_banks()
That function has u64 parameter for start[] and size[]. Maybe U-Boot configures our 4GB RAM with 2 banks but still assumes each one is 1GB size.
Now, the boring part begins: going through code to find out how the parameters are set by the board file...
I think I have it running. Cleaned up patch is coming.
Here it is:
http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=0c5e26e7886ea7d2d934f...
I have moved the emif definition to lc15.c so that this patch is self-contained and does not depend on upstream u-boot.
This is forgiveable since we can and do not want to change the DRAM e.g. on the OMAP5EVM...
The only ugly issue is that I have no idea if we can auto-detect the RAM type / size. And we forgot to assign different CPU board version resistors.
So it either works or the other u-boot.img has to be installed on the SD card.
This makes swapping bootable SD cards between both variants impossible. Which is annoying since(I always forget to write on them what they are good for...
You have to use either
pandora_pyra_lc15_4gb_defconfig for 4GB pandora_pyra_lc15_defconfig for 2GB
I have only tested if the lpae kernel works with 4GB and the non-lpae kernel works with 2GB.
BR, Nikolaus
-
H. Nikolaus Schaller -
Matthijs van Duin