On 13 November 2015 at 13:25, Tom Rini trini@konsulko.com wrote:
On Fri, Nov 13, 2015 at 08:26:31AM +0000, Ryan Harkin wrote:
Hi Tom,
Thanks for coming back to this.
On 12 November 2015 at 20:58, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 26, 2015 at 11:00:22AM +0000, Ryan Harkin wrote:
This patch makes the 2nd DRAM bank available on Juno only and not on other vexpress64 targets, eg. the FVP models.
The commit below added a 2nd bank of NOR flash for Juno, but also for all vexpress64 targets:
commit 2d0cee1ca2b9d977fa3214896bb2e30cfec77059 Author: Liviu Dudau <Liviu.Dudau@foss.arm.com> Date: Mon Oct 19 11:08:31 2015 +0100 vexpress64: Juno: Declare all 8GB of RAM and make them visible to the kernel. Juno comes with 8GB RAM, but U-Boot only passes 2GB to the kernel. Declare a secondary memory bank and set the sizes correctly. Signed-off-by: Liviu Dudau <Liviu.Dudau@foss.arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ryan Harkin <ryan.harkin@linaro.org> Tested-by: Ryan Harkin <ryan.harkin@linaro.org>Unfortunately, I only fully tested on Juno R0, R1 and the FVP Foundation model. Whilst FVP Base AEMV8 models run U-Boot OK, they fail to boot the kernel.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Acked-by: Liviu Dudau liviu.dudau@foss.arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org
This breaks building of vexpress_aemv8a_semi :(
Yes, I see the problem now :(
If I apply this to pure upstream, I get this error, which I assume is the same as yours:
board/armltd/vexpress64/pcie.c: In function 'xr3pci_setup_atr': board/armltd/vexpress64/pcie.c:111:29: error: 'PHYS_SDRAM_2' undeclared (first use in this function) xr3pci_set_atr_entry(base, PHYS_SDRAM_2, PHYS_SDRAM_2,
This error was fixed by Linus Walleij's patch that I carry in my u-boot fork:
[PATCH] vexpress64: compile Juno PCIe conditionally
I'd prefer that Linus' patch is merged, then mine, but if you don't want to do that, I can change my patch so that PHYS_SDRAM_2 isn't used if it isn't defined.
Didn't I ask for some changes on that PCIe patch?
Good point. I thought you'd grudgingly accepted it, but I see your last comment was:
"Yes, thanks. I think it's just a style thing then. We don't do a lot of static inline nop functions, we do __weak functions in the main file (and comment about what it should be doing in a real function) and then provide the strong version in another file. So just the pcie.h part needs changing then."
I'll ping Linus about it on his thread and see if he wants to issue a v2. Then I'll come back to this patch later.
Thanks, Ryan.