tegra124: nyan-big: LPAE not working
A message that is not in the archive (sent off-list or not yet received): 20190211093829.GA3725@ulmo
A message that is not in the archive (sent off-list or not yet received): 20190211100437.Horde.N5S1UaNJsgMKD0ev6Zb_ckb@_
Quoted 87 lines · Tristan Bastian
Thierry Reding – Mon, 11. February 2019 10:38
Quoted 70 lines · Tristan Bastian
Quoted 6 lines
Thierry Reding – Mon, 11. February 2019 9:52
Quoted 4 lines · Tristan Bastian
Quoted 3 lines
Thierry, do you have any news on this?
I don't think, that google is going to push an updated version of
coreboot
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to each nyan-big device..
So reverting this patch at least for the nyan devices would be the bestI
Quoted 10 lines
Quoted 6 lines
Quoted 1 line
think..
Yes, I agree. I had a brief chat with Rob Herring about this and he too agrees that we should revert it for now. I'll make it a manual revert and add a comment to the device tree node that will hopefully avoid any future janitorial "cleanups" of this sort.
great news! :)
Quoted 1 line
Quoted 1 line
BTW: I'm now running u-boot natively and it seems like u-boot always has
a
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
problem with the memory..
If u-boot is used chainloaded to coreboot it is only getting 2GB ofmemory
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
and running u-boot natively also just gives me 2GB..
I've tested that with a kernel with "ARM: tegra: Fixunit_address_vs_regDTC
Quoted 1 line
Quoted 1 line
Quoted 1 line
warnings for /memory" reverted and also on a kernel, before this patch
was
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
applied..
It's possible that U-Boot doesn't support LPAE and therefore may not be able to use more than the 2 GiB of memory.
Quoted 7 lines
So I at least enabled LPAE in u-boot with "
CONFIG_ARMV7_LPAE=y" and this was for some reason also needed to get some output on the display..
I'm not sure why LPAE needs to activated in u-boot for display output on the nyan-big..
Without LPAE enabled u-boot was still working, and booted linux, but u-boot didn't display anything on screen, linux then did..Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not enough memory for the framebuffer? There should be plenty, so maybe there is something else going on here.
Quoted 8 lines
Quoted 3 lines
However, U-Boot should be
able to tell the kernel exactly how much memory the system has and pass that on via device tree. That still does work, right?It seems like this is not working..
And this seems to be the case with both, u-boot chainloaded and running u-boot natively..Quoted 6 lines
I've used these scripts for flashing:
github.com/NVIDIA/tegra-uboot-flasher-scripts
And used the norrin device since it seems like it is the nyan-big dev board?
But going with the norrin device config should not be the issue here since the problem also exists when chainloading u-boot, right?It could be a problem. The memory bank configuration is stored in what's called a BCT along with a bunch of other parameters that define what the memory controller needs to access the given memory chips. So if you've flashed a BCT that's for a board with only 2 GiB of memory you would end up with a system that can't address any more than that. It's somewhat surprising that memory accesses work at all with a BCT that's for different memory chips, but sometimes you can get lucky.
Quoted 6 lines
You may want to try reflashing with the right BCT. The simplest would probably be to duplicate the cbootimage configuration for Norrin and substitute the relevant bits by what you have from the Chromebook flash utilities. Looks like the BCT in really the only thing you can replace there. Make sure to replace it with the one that matches your Chromebook and it should give you the right memory bank configuration.
Is there a way to check if the correct bct for my 4GB model was used? What I tried was to edit the existing bct config file of norrin from here:
https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg
by replacing all entries for each memory bank with the entries from here:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.inc
Quoted 4 lines
I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of each line.. This also booted for me, but also just leaves me with only 2Gb of my 4GB..
And since this problem also occurs, when chainloading u-boot, this must be a problem with u-boot, I think..
Not necessarily. U-Boot reads the memory size from EMC registers and those EMC registers are programmed based on the contents of the BCT. So if the BCT is wrong, then it's going to be wrong irrespective of what bootloader you use.
That said, I does indeed look as if U-Boot only supports 2 GiB of memory on 32-bit Tegra. arch/arm/mach-tegra/board.c contains the relevant code. If you look at dram_init() it uses query_sdram_size() to get the size of RAM. That will allow to convey up to 4 GiB of RAM, but then the code in board2.c (see dram_init_banksize()) only uses a single bank on 32-bit Tegra (CONFIG_PHYS_64BIT is only set for 64-bit Tegra).
According to the comments for dram_init_bank_size() we can't store the second bank because the .start field is 32 bits wide and therefore can't store the 0x100000000 start address for the bank.
It sounds to me like ARMV7_LPAE should perhaps select PHYS_64BIT to make sure all the appropriate variables can store addresses beyond the 32-bit boundary. It's one thing to not support > 2 GiB of memory in U-Boot, but it's an entirely different story if we can't even pass > GiB of memory to the kernel if they exist.
Stephen, do you remember if there was anything preventing us from going 64-bit for phys_addr_t and phys_size_t on LPAE enabled systems?
Cc Tom for visibility and U-Boot since this is a U-Boot bug.
Thierry
Quoted 16 lines
Tristan
Quoted 14 lines
Quoted 8 lines
Simon Glass used his servo board to enter the tegrarcm mode:
patchwork.ozlabs.org/patch/1019003/I had to erase the internal SPI flash in order to boot into the tegrarcm mode..
Do you have some instructions or internal documentation to tell me, if some of the unpopulated buttons on the nyan-big mainboard can be used to enter the tegrarcm state?You should be able to boot into recovery mode with the "enterrcm" command in U-Boot. I'm not aware of any buttons on the mainboard that can be used for this, unfortunately.
Thierry
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
Am 11.02.19 um 11:48 schrieb Thierry Reding:
Quoted 87 lines · Tristan Bastian
Quoted 77 lines
Thierry Reding – Mon, 11. February 2019 10:38
Quoted 62 lines · Tristan Bastian
Quoted 5 lines
Thierry Reding – Mon, 11. February 2019 9:52
Quoted 4 lines · Tristan Bastian
Quoted 3 lines
Thierry, do you have any news on this?
I don't think, that google is going to push an updated version of
coreboot
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to each nyan-big device..
So reverting this patch at least for the nyan devices would be the bestI
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
think..
Yes, I agree. I had a brief chat with Rob Herring about this and he too agrees that we should revert it for now. I'll make it a manual revert and add a comment to the device tree node that will hopefully avoid any future janitorial "cleanups" of this sort.
great news! :)
Quoted 1 line
Quoted 1 line
BTW: I'm now running u-boot natively and it seems like u-boot always has
a
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
problem with the memory..
If u-boot is used chainloaded to coreboot it is only getting 2GB ofmemory
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
and running u-boot natively also just gives me 2GB..
I've tested that with a kernel with "ARM: tegra: Fixunit_address_vs_regDTC
Quoted 1 line
Quoted 1 line
Quoted 1 line
warnings for /memory" reverted and also on a kernel, before this patch
was
Quoted 10 lines
Quoted 3 lines
Quoted 1 line
applied..
It's possible that U-Boot doesn't support LPAE and therefore may not be able to use more than the 2 GiB of memory.
So I at least enabled LPAE in u-boot with "
CONFIG_ARMV7_LPAE=y" and this was for some reason also needed to get some output on the display..
I'm not sure why LPAE needs to activated in u-boot for display output on the nyan-big..
Without LPAE enabled u-boot was still working, and booted linux, but u-boot didn't display anything on screen, linux then did..Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not enough memory for the framebuffer? There should be plenty, so maybe there is something else going on here.
Quoted 7 lines
Quoted 3 lines
However, U-Boot should be
able to tell the kernel exactly how much memory the system has and pass that on via device tree. That still does work, right?It seems like this is not working..
And this seems to be the case with both, u-boot chainloaded and running u-boot natively..Quoted 6 lines
I've used these scripts for flashing:
github.com/NVIDIA/tegra-uboot-flasher-scripts
And used the norrin device since it seems like it is the nyan-big dev board?
But going with the norrin device config should not be the issue here since the problem also exists when chainloading u-boot, right?It could be a problem. The memory bank configuration is stored in what's called a BCT along with a bunch of other parameters that define what the memory controller needs to access the given memory chips. So if you've flashed a BCT that's for a board with only 2 GiB of memory you would end up with a system that can't address any more than that. It's somewhat surprising that memory accesses work at all with a BCT that's for different memory chips, but sometimes you can get lucky.
Quoted 6 lines
You may want to try reflashing with the right BCT. The simplest would probably be to duplicate the cbootimage configuration for Norrin and substitute the relevant bits by what you have from the Chromebook flash utilities. Looks like the BCT in really the only thing you can replace there. Make sure to replace it with the one that matches your Chromebook and it should give you the right memory bank configuration.
Is there a way to check if the correct bct for my 4GB model was used? What I tried was to edit the existing bct config file of norrin from here:
https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg
by replacing all entries for each memory bank with the entries from here:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.incQuoted 4 lines
I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of each line.. This also booted for me, but also just leaves me with only 2Gb of my 4GB..
And since this problem also occurs, when chainloading u-boot, this must be a problem with u-boot, I think..
Not necessarily. U-Boot reads the memory size from EMC registers and those EMC registers are programmed based on the contents of the BCT. So if the BCT is wrong, then it's going to be wrong irrespective of what bootloader you use.
Quoted 6 lines
That said, I does indeed look as if U-Boot only supports 2 GiB of memory on 32-bit Tegra.
arch/arm/mach-tegra/board.ccontains the relevant code. If you look atdram_init()it usesquery_sdram_size()to get the size of RAM. That will allow to convey up to 4 GiB of RAM, but then the code inboard2.c(seedram_init_banksize()) only uses a single bank on 32-bit Tegra (CONFIG_PHYS_64BITis only set for 64-bit Tegra).
I've enabled "CONFIG_PHYS_64BIT" for testing and it seems to be at least helping. I'm getting a bunch of compile warnings about casting pointers from integers of different size..
But I'm getting 4GB of memory now if I boot via an extlinux.conf file. :) Unfortunately this makes some other things unusable, like efi booting is no longer working for me.. I'm getting the following error when trying to efi boot grub2:
free magic is broken at 0xe59ff3f8: 0xffffffff
And if I try to boot again (without resetting) via efi I'm getting:
fdt_root: FDT_ERR_BADMAGIC
ERROR: root node setup failed
- must RESET the board to recover
Tristan
Quoted 10 lines
According to the comments for
dram_init_bank_size()we can't store the second bank because the .start field is 32 bits wide and therefore can't store the0x100000000start address for the bank.It sounds to me like
ARMV7_LPAEshould perhaps selectPHYS_64BITto make sure all the appropriate variables can store addresses beyond the 32-bit boundary. It's one thing to not support > 2 GiB of memory in U-Boot, but it's an entirely different story if we can't even pass > GiB of memory to the kernel if they exist.
Quoted 22 lines
Stephen, do you remember if there was anything preventing us from going 64-bit for
phys_addr_tandphys_size_ton LPAE enabled systems?Cc Tom for visibility and U-Boot since this is a U-Boot bug.
Thierry
Quoted 15 lines
Tristan
Quoted 13 lines
Quoted 8 lines
Simon Glass used his servo board to enter the tegrarcm mode:
patchwork.ozlabs.org/patch/1019003/I had to erase the internal SPI flash in order to boot into the tegrarcm mode..
Do you have some instructions or internal documentation to tell me, if some of the unpopulated buttons on the nyan-big mainboard can be used to enter the tegrarcm state?You should be able to boot into recovery mode with the "enterrcm" command in U-Boot. I'm not aware of any buttons on the mainboard that can be used for this, unfortunately.
Thierry
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
Quoted 109 lines · Thierry Reding
Quoted 87 lines · Tristan Bastian
Thierry Reding – Mon, 11. February 2019 10:38
Quoted 70 lines · Tristan Bastian
Quoted 6 lines
Thierry Reding – Mon, 11. February 2019 9:52
Quoted 4 lines · Tristan Bastian
Quoted 3 lines
Thierry, do you have any news on this?
I don't think, that google is going to push an updated version of
coreboot
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to each nyan-big device..
So reverting this patch at least for the nyan devices would be the bestI
Quoted 10 lines
Quoted 6 lines
Quoted 1 line
think..
Yes, I agree. I had a brief chat with Rob Herring about this and he too agrees that we should revert it for now. I'll make it a manual revert and add a comment to the device tree node that will hopefully avoid any future janitorial "cleanups" of this sort.
great news! :)
Quoted 1 line
Quoted 1 line
BTW: I'm now running u-boot natively and it seems like u-boot always has
a
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
problem with the memory..
If u-boot is used chainloaded to coreboot it is only getting 2GB ofmemory
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
and running u-boot natively also just gives me 2GB..
I've tested that with a kernel with "ARM: tegra: Fixunit_address_vs_regDTC
Quoted 1 line
Quoted 1 line
Quoted 1 line
warnings for /memory" reverted and also on a kernel, before this patch
was
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
applied..
It's possible that U-Boot doesn't support LPAE and therefore may not be able to use more than the 2 GiB of memory.
Quoted 7 lines
So I at least enabled LPAE in u-boot with "
CONFIG_ARMV7_LPAE=y" and this was for some reason also needed to get some output on the display..
I'm not sure why LPAE needs to activated in u-boot for display output on the nyan-big..
Without LPAE enabled u-boot was still working, and booted linux, but u-boot didn't display anything on screen, linux then did..Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not enough memory for the framebuffer? There should be plenty, so maybe there is something else going on here.
Quoted 8 lines
Quoted 3 lines
However, U-Boot should be
able to tell the kernel exactly how much memory the system has and pass that on via device tree. That still does work, right?It seems like this is not working..
And this seems to be the case with both, u-boot chainloaded and running u-boot natively..Quoted 6 lines
I've used these scripts for flashing:
github.com/NVIDIA/tegra-uboot-flasher-scripts
And used the norrin device since it seems like it is the nyan-big dev board?
But going with the norrin device config should not be the issue here since the problem also exists when chainloading u-boot, right?It could be a problem. The memory bank configuration is stored in what's called a BCT along with a bunch of other parameters that define what the memory controller needs to access the given memory chips. So if you've flashed a BCT that's for a board with only 2 GiB of memory you would end up with a system that can't address any more than that. It's somewhat surprising that memory accesses work at all with a BCT that's for different memory chips, but sometimes you can get lucky.
Quoted 6 lines
You may want to try reflashing with the right BCT. The simplest would probably be to duplicate the cbootimage configuration for Norrin and substitute the relevant bits by what you have from the Chromebook flash utilities. Looks like the BCT in really the only thing you can replace there. Make sure to replace it with the one that matches your Chromebook and it should give you the right memory bank configuration.
Is there a way to check if the correct bct for my 4GB model was used? What I tried was to edit the existing bct config file of norrin from here:
https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg
by replacing all entries for each memory bank with the entries from here:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.incQuoted 4 lines
I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of each line.. This also booted for me, but also just leaves me with only 2Gb of my 4GB..
And since this problem also occurs, when chainloading u-boot, this must be a problem with u-boot, I think..
Not necessarily. U-Boot reads the memory size from EMC registers and those EMC registers are programmed based on the contents of the BCT. So if the BCT is wrong, then it's going to be wrong irrespective of what bootloader you use.
That said, I does indeed look as if U-Boot only supports 2 GiB of memory on 32-bit Tegra.
arch/arm/mach-tegra/board.ccontains the relevant code. If you look atdram_init()it usesquery_sdram_size()to get the size of RAM. That will allow to convey up to 4 GiB of RAM, but then the code inboard2.c(seedram_init_banksize()) only uses a single bank on 32-bit Tegra (CONFIG_PHYS_64BITis only set for 64-bit Tegra).According to the comments for
dram_init_bank_size()we can't store the second bank because the .start field is 32 bits wide and therefore can't store the0x100000000start address for the bank.
Quoted 8 lines
It sounds to me like
ARMV7_LPAEshould perhaps selectPHYS_64BITto make sure all the appropriate variables can store addresses beyond the 32-bit boundary. It's one thing to not support > 2 GiB of memory in U-Boot, but it's an entirely different story if we can't even pass > GiB of memory to the kernel if they exist.Stephen, do you remember if there was anything preventing us from going 64-bit for
phys_addr_tandphys_size_ton LPAE enabled systems?
We probably just never tried since we never needed it and/or LPAE wasn't available (in U-Boot SW) when it initially might have been useful. I would not be surprised if some of the low-level Tegra code in U-Boot conflates 64-bit support with SoC being >= T210, so things might not be as simple as enabling CONFIG_PHYS_64BIT, but you never know...
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
Hi there
Quoted 172 lines · Stephen Warren
Quoted 167 lines · Thierry Reding
Quoted 122 lines · Tristan Bastian
Thierry Reding – Mon, 11. February 2019 10:38
Quoted 98 lines
Quoted 7 lines · Tristan Bastian
Thierry Reding – Mon, 11. February 2019 9:52
Quoted 6 lines
Quoted 4 lines · Tristan Bastian
Thierry, do you have any news on this?
I don't think, that google is going to push an updated version of
coreboot
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
to each nyan-big device..
So reverting this patch at least for the nyan devices would be the bestI
Quoted 10 lines
Quoted 9 lines
Quoted 1 line
think..
Yes, I agree. I had a brief chat with Rob Herring about this and he too
agrees that we should revert it for now. I'll make it a manual revert
and add a comment to the device tree node that will hopefully avoid any
future janitorial "cleanups" of this sort.Quoted 4 lines
great news! :)
Quoted 2 lines
Quoted 2 lines
BTW: I'm now running u-boot natively and it seems like u- boot always has
a
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
problem with the memory..
If u-boot is used chainloaded to coreboot it is only getting 2GB ofmemory
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
and running u-boot natively also just gives me 2GB.. I've tested that with a kernel with "ARM: tegra: Fix
unit_address_vs_regDTC
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
warnings for /memory" reverted and also on a kernel, before this patch
was
Quoted 6 lines
Quoted 5 lines
Quoted 1 line
applied..
It's possible that U-Boot doesn't support LPAE and therefore may not be
able to use more than the 2 GiB of memory.Quoted 11 lines
So I at least enabled LPAE in u-boot with "
CONFIG_ARMV7_LPAE=y" and
this was for some reason also needed to get some output on the
display..
I'm not sure why LPAE needs to activated in u-boot for display output
on the nyan-big..
Without LPAE enabled u-boot was still working, and booted linux, but
u-boot didn't display anything on screen, linux then did..Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not
enough memory for the framebuffer? There should be plenty, so maybe
there is something else going on here.Quoted 10 lines
Quoted 4 lines
However, U-Boot should be
able to tell the kernel exactly how much memory the system has and pass
that on via device tree. That still does work, right?It seems like this is not working..
And this seems to be the case with both, u-boot chainloaded and
running u-boot natively..Quoted 9 lines
I've used these scripts for flashing:
github.com/NVIDIA/tegra-uboot-flasher-scripts And used the norrin device since it seems like it is the nyan-big dev
board?
But going with the norrin device config should not be the issue here
since the problem also exists when chainloading u-boot, right?It could be a problem. The memory bank configuration is stored in what's
called a BCT along with a bunch of other parameters that define what the
memory controller needs to access the given memory chips. So if you've
flashed a BCT that's for a board with only 2 GiB of memory you would end
up with a system that can't address any more than that. It's somewhat
surprising that memory accesses work at all with a BCT that's for
different memory chips, but sometimes you can get lucky.Quoted 11 lines
You may want to try reflashing with the right BCT. The simplest would
probably be to duplicate the cbootimage configuration for Norrin and
substitute the relevant bits by what you have from the Chromebook flash
utilities. Looks like the BCT in really the only thing you can replace
there. Make sure to replace it with the one that matches your Chromebook
and it should give you the right memory bank configuration.Is there a way to check if the correct bct for my 4GB model was used?
What I tried was to edit the existing bct config file of norrin from here:
https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg
by replacing all entries for each memory bank with the entries from here:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.incQuoted 7 lines
I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of each line..
This also booted for me, but also just leaves me with only 2Gb of my 4GB..And since this problem also occurs, when chainloading u-boot, this must be a problem with u-boot, I think..
Not necessarily. U-Boot reads the memory size from EMC registers and
those EMC registers are programmed based on the contents of the BCT. So
if the BCT is wrong, then it's going to be wrong irrespective of what
bootloader you use.That said, I does indeed look as if U-Boot only supports 2 GiB of memory
on 32-bit Tegra.arch/arm/mach-tegra/board.ccontains the relevant code.
If you look atdram_init()it usesquery_sdram_size()to get the size of
RAM. That will allow to convey up to 4 GiB of RAM, but then the code inboard2.c(seedram_init_banksize()) only uses a single bank on 32- bit
Tegra (CONFIG_PHYS_64BITis only set for 64-bit Tegra).According to the comments for
dram_init_bank_size()we can't store the
second bank because the .start field is 32 bits wide and therefore can't
store the0x100000000start address for the bank.It sounds to me like
ARMV7_LPAEshould perhaps selectPHYS_64BITto make
sure all the appropriate variables can store addresses beyond the 32-bit
boundary. It's one thing to not support > 2 GiB of memory in U- Boot, but
it's an entirely different story if we can't even pass > GiB of memory
to the kernel if they exist.Quoted 3 lines
Stephen, do you remember if there was anything preventing us from going
64-bit forphys_addr_tandphys_size_ton LPAE enabled systems?
Quoted 7 lines
We probably just never tried since we never needed it and/or LPAE wasn't
available (in U-Boot SW) when it initially might have been useful. I would not be surprised if some of the low-level Tegra code in U-Boot conflates 64-bit support with SoC being >= T210, so things might not be
as simple as enablingCONFIG_PHYS_64BIT, but you never know...
Interesting discussion but I have to admit that I also only tested LPAE once on the 4GB TK1 Chromebook running stock boot loader.
Unfortunately, the 4GB Apalis TK1 SKU got cancelled down the road so I never got to actually really needing any of this in U-Boot. Sorry, not being of much help here...
Cheers
Marcel
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
Quoted 118 lines · Stephen Warren
Quoted 117 lines · Thierry Reding
Quoted 85 lines · Tristan Bastian
Thierry Reding – Mon, 11. February 2019 10:38
Quoted 70 lines · Tristan Bastian
Quoted 6 lines
Thierry Reding – Mon, 11. February 2019 9:52
Quoted 4 lines · Tristan Bastian
Quoted 3 lines
Thierry, do you have any news on this?
I don't think, that google is going to push an updated version of
coreboot
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to each nyan-big device..
So reverting this patch at least for the nyan devices would be the bestI
Quoted 10 lines
Quoted 6 lines
Quoted 1 line
think..
Yes, I agree. I had a brief chat with Rob Herring about this and he too agrees that we should revert it for now. I'll make it a manual revert and add a comment to the device tree node that will hopefully avoid any future janitorial "cleanups" of this sort.
great news! :)
Quoted 1 line
Quoted 1 line
BTW: I'm now running u-boot natively and it seems like u-boot always has
a
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
problem with the memory..
If u-boot is used chainloaded to coreboot it is only getting 2GB ofmemory
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
and running u-boot natively also just gives me 2GB..
I've tested that with a kernel with "ARM: tegra: Fixunit_address_vs_regDTC
Quoted 1 line
Quoted 1 line
Quoted 1 line
warnings for /memory" reverted and also on a kernel, before this patch
was
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
applied..
It's possible that U-Boot doesn't support LPAE and therefore may not be able to use more than the 2 GiB of memory.
Quoted 7 lines
So I at least enabled LPAE in u-boot with "
CONFIG_ARMV7_LPAE=y" and this was for some reason also needed to get some output on the display..
I'm not sure why LPAE needs to activated in u-boot for display output on the nyan-big..
Without LPAE enabled u-boot was still working, and booted linux, but u-boot didn't display anything on screen, linux then did..Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not enough memory for the framebuffer? There should be plenty, so maybe there is something else going on here.
Quoted 8 lines
Quoted 3 lines
However, U-Boot should be
able to tell the kernel exactly how much memory the system has and pass that on via device tree. That still does work, right?It seems like this is not working..
And this seems to be the case with both, u-boot chainloaded and running u-boot natively..Quoted 6 lines
I've used these scripts for flashing:
github.com/NVIDIA/tegra-uboot-flasher-scripts
And used the norrin device since it seems like it is the nyan-big dev board?
But going with the norrin device config should not be the issue here since the problem also exists when chainloading u-boot, right?It could be a problem. The memory bank configuration is stored in what's called a BCT along with a bunch of other parameters that define what the memory controller needs to access the given memory chips. So if you've flashed a BCT that's for a board with only 2 GiB of memory you would end up with a system that can't address any more than that. It's somewhat surprising that memory accesses work at all with a BCT that's for different memory chips, but sometimes you can get lucky.
Quoted 6 lines
You may want to try reflashing with the right BCT. The simplest would probably be to duplicate the cbootimage configuration for Norrin and substitute the relevant bits by what you have from the Chromebook flash utilities. Looks like the BCT in really the only thing you can replace there. Make sure to replace it with the one that matches your Chromebook and it should give you the right memory bank configuration.
Is there a way to check if the correct bct for my 4GB model was used? What I tried was to edit the existing bct config file of norrin from here:
https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfgQuoted 8 lines
by replacing all entries for each memory bank with the entries from here:
https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.incI also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of each line.. This also booted for me, but also just leaves me with only 2Gb of my 4GB..
And since this problem also occurs, when chainloading u-boot, this must be a problem with u-boot, I think..
Not necessarily. U-Boot reads the memory size from EMC registers and those EMC registers are programmed based on the contents of the BCT. So if the BCT is wrong, then it's going to be wrong irrespective of what bootloader you use.
That said, I does indeed look as if U-Boot only supports 2 GiB of memory on 32-bit Tegra.
arch/arm/mach-tegra/board.ccontains the relevant code. If you look atdram_init()it usesquery_sdram_size()to get the size of RAM. That will allow to convey up to 4 GiB of RAM, but then the code inboard2.c(seedram_init_banksize()) only uses a single bank on 32-bit Tegra (CONFIG_PHYS_64BITis only set for 64-bit Tegra).According to the comments for
dram_init_bank_size()we can't store the second bank because the .start field is 32 bits wide and therefore can't store the0x100000000start address for the bank.It sounds to me like
ARMV7_LPAEshould perhaps selectPHYS_64BITto make sure all the appropriate variables can store addresses beyond the 32-bit boundary. It's one thing to not support > 2 GiB of memory in U-Boot, but it's an entirely different story if we can't even pass > GiB of memory to the kernel if they exist.
Quoted 4 lines
Quoted 2 lines
Stephen, do you remember if there was anything preventing us from going 64-bit for
phys_addr_tandphys_size_ton LPAE enabled systems?We probably just never tried since we never needed it and/or LPAE wasn't available (in U-Boot SW) when it initially might have been useful. I would not be surprised if some of the low-level Tegra code in U-Boot conflates 64-bit support with SoC being >= T210, so things might not be as simple as enabling
CONFIG_PHYS_64BIT, but you never know...
Good Evening,
I have finally built mainline u-boot for the rk3328-roc-cc board, and have actually run into this issue as well. With the downstream 2017 u-boot, the board correctly reports 4GB to the kernel.
With mainline, no matter what I try, the kernel only ever sees 2GB.
I don't see any significant differences between the spin-up code from the downstream u-boot to the mainline u-boot.
I am starting to wonder if this is a u-boot regression, but since most embedded SBCs don't use 4GB of ram it does not crop up often. Of course I may just be missing something, since this is my first foray into u-boot.
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot