On Thu, Jul 29, 2021 at 06:47:02PM +0200, Marek Vasut wrote:
On 7/29/21 5:23 PM, Tom Rini wrote:
On Thu, Jul 29, 2021 at 05:01:09PM +0200, Marek Vasut wrote:
On 7/29/21 9:22 AM, Jan Kiszka wrote:
From: Jan Kiszka jan.kiszka@siemens.com
This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
While the goal is valid and there is surely unused memory in that area, we also have a lot of crucial things still located at the top-of-memory while running lmb_alloc_base. Such things are the page table (tlb_addr), relocated U-Boot and the active stack. Possibly more. So this patch was premature, we will need relocations of those things first if we want to use the range.
Fixes booting on the IOT2050, but likely also on other boards. It got stuck on relocating the FDT - over the relocated U-Boot code.
Signed-off-by: Jan Kiszka jan.kiszka@siemens.com
Practically,
void arch_lmb_reserve(struct lmb *lmb) { lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr); }
So this is wrong and breaks a use case on rcar3, where there is more stuff which should not be reserved until the ram top.
I suspect the real fix here is to protect only the stack and tlb on arm64, not just everything from current stack bottom to ram top ?
Wait, what? There's never been a U-Boot release that didn't reserve that area
That does not mean such a huge reservation is correct.
I apologize for not being overly clear in my answer, I already told Jan I am highly overloaded and simply lack the capacity to analyze this problem thoroughly on a short notice.
I understand.
so when did rcar3 introduce something there that shouldn't be reserved? And you had phrased this to me on IRC as about reserving spot for ATAGS, and that not being needed of course on arm64. But that's not what's going on. Perhaps the answer is that rcar3 needs to introduce a board_lmb_reserve to free the normal arch one and provide whatever more narrow scope it needs.
Based on the commit message 2359fa7a878 ("arm: bootm: Disable LMB reservation for command line and board info on arm64") , this is about ATAGS and we really don't need to reserve those on arm64.
Commit 2359fa7a878 disables the entire arch_lmb_reserve function on aarch64, yes. I assumed when we had talked that it was a small area being set aside and perhaps mis-recalled that ATAGS tended to live at DDR_BASE + 0x800 or so. This reservation is not at that spot, and a lot more than that. That commit is also only present in v2021.10-rc1 so it's not a great idea for another project to depend on it and can also revert their changes until someone is able to analyze the entire situation again.
I didn't hit the tlb reservation issue Jan has in my tests on rcar3, so I suspect that is the real problem here, i.e. we need some more fine grained lmb reservation on arm64 ?
Yes, some further analysis is needed here. But due to a lack of time I suspect the best answer for now is for rcar3 to add board_lmb_reserve() and lmb_free what's not needed there.