[U-Boot] 64Bit device tree compilation
Hi Simon,
My name is Hanna, I'm working in Software team in Marvell with Yehuda.
I'm trying to run U-Boot with FDT in 64Bit. I've issue when I'm trying to load the image on my board, I got abort (**Synchronous Abort**) Exactly when the U-boot run fdt_addr_to_cpu(*cell) under lib/fdtdec.c
The issue is the format of the FDT is 32Bit, and Big Endian mode.
After some debug, I changed the typedef of fdt_size, and fdt_addr to be u32. Also fdt_addr_to_cpu, and fdt_size_to_cpu to use u32 swap, it works.
My question is: Is that correct to change the typedef to use u32Bit?
Thanks, Hanna
Hi Hanna,
On 18 March 2015 at 11:17, Hanna Hawa hannah@marvell.com wrote:
Hi Simon,
My name is Hanna, I’m working in Software team in Marvell with Yehuda.
I’m trying to run U-Boot with FDT in 64Bit.
I’ve issue when I’m trying to load the image on my board, I got abort (**Synchronous Abort**)
Exactly when the U-boot run fdt_addr_to_cpu(*cell) under lib/fdtdec.c
The issue is the format of the FDT is 32Bit, and Big Endian mode.
After some debug, I changed the typedef of fdt_size, and fdt_addr to be u32.
Also fdt_addr_to_cpu, and fdt_size_to_cpu to use u32 swap, it works.
My question is:
Is that correct to change the typedef to use u32Bit?
What do you have CONFIG_PHYS_64BIT set to? That is supposed to indicate the machine word size. Do you have a 64-bit CPU?
I recall someone reporting that on 64-bit machines things like '*cell' can fail because the address is not always 64-bit aligned. But on 64-bit machines, fdt_addr_t should be 64-bit, so changing it to 32-bit seems wrong since you may not be able to address everything (e.g. the reg properties will be limited to the first 4GB).
I suspect it is wrong to use *cell. Instead we could use fdtdec_get_number(cell, <size>) or similar logic. Any existing use of fdt_addr_t/fdt_size_t to access a cell is wrong, i.e. in fdtdec_get_addr_size() and fdtdec_decode_region(). You could send a patch for that.
Regards, Simon
On Thu, Mar 19, 2015 at 07:43:35AM -0600, Simon Glass wrote:
Hi Hanna,
On 18 March 2015 at 11:17, Hanna Hawa hannah@marvell.com wrote:
Hi Simon,
My name is Hanna, I’m working in Software team in Marvell with Yehuda.
I’m trying to run U-Boot with FDT in 64Bit.
I’ve issue when I’m trying to load the image on my board, I got abort (**Synchronous Abort**)
Exactly when the U-boot run fdt_addr_to_cpu(*cell) under lib/fdtdec.c
The issue is the format of the FDT is 32Bit, and Big Endian mode.
After some debug, I changed the typedef of fdt_size, and fdt_addr to be u32.
Also fdt_addr_to_cpu, and fdt_size_to_cpu to use u32 swap, it works.
My question is:
Is that correct to change the typedef to use u32Bit?
What do you have CONFIG_PHYS_64BIT set to? That is supposed to indicate the machine word size. Do you have a 64-bit CPU?
I recall someone reporting that on 64-bit machines things like '*cell' can fail because the address is not always 64-bit aligned. But on 64-bit machines, fdt_addr_t should be 64-bit, so changing it to 32-bit seems wrong since you may not be able to address everything (e.g. the reg properties will be limited to the first 4GB).
I suspect it is wrong to use *cell. Instead we could use fdtdec_get_number(cell, <size>) or similar logic. Any existing use of fdt_addr_t/fdt_size_t to access a cell is wrong, i.e. in fdtdec_get_addr_size() and fdtdec_decode_region(). You could send a patch for that.
I have a couple of patches for this kind of issue that I encountered during recent bring-up of 64-bit U-Boot on Tegra210. I'm on my way out of the office right now, but I'll send out the patches tomorrow.
Thierry
Hi,
On Fri, Mar 20, 2015 at 2:04 AM, Thierry Reding thierry.reding@gmail.com wrote:
On Thu, Mar 19, 2015 at 07:43:35AM -0600, Simon Glass wrote:
Hi Hanna,
On 18 March 2015 at 11:17, Hanna Hawa hannah@marvell.com wrote:
Hi Simon,
My name is Hanna, I’m working in Software team in Marvell with Yehuda.
I’m trying to run U-Boot with FDT in 64Bit.
I’ve issue when I’m trying to load the image on my board, I got abort (**Synchronous Abort**)
Exactly when the U-boot run fdt_addr_to_cpu(*cell) under lib/fdtdec.c
The issue is the format of the FDT is 32Bit, and Big Endian mode.
After some debug, I changed the typedef of fdt_size, and fdt_addr to be u32.
Also fdt_addr_to_cpu, and fdt_size_to_cpu to use u32 swap, it works.
My question is:
Is that correct to change the typedef to use u32Bit?
What do you have CONFIG_PHYS_64BIT set to? That is supposed to indicate the machine word size. Do you have a 64-bit CPU?
I recall someone reporting that on 64-bit machines things like '*cell' can fail because the address is not always 64-bit aligned. But on 64-bit machines, fdt_addr_t should be 64-bit, so changing it to 32-bit seems wrong since you may not be able to address everything (e.g. the reg properties will be limited to the first 4GB).
I suspect it is wrong to use *cell. Instead we could use fdtdec_get_number(cell, <size>) or similar logic. Any existing use of fdt_addr_t/fdt_size_t to access a cell is wrong, i.e. in fdtdec_get_addr_size() and fdtdec_decode_region(). You could send a patch for that.
I have a couple of patches for this kind of issue that I encountered during recent bring-up of 64-bit U-Boot on Tegra210. I'm on my way out of the office right now, but I'll send out the patches tomorrow.
Maybe a dumb question, why do we need to have a 64-bit U-Boot for arm64? I don't see we ever created 64-bit U-Boot for ppc64.
Regards, Bin
Hi,
Maybe a dumb question, why do we need to have a 64-bit U-Boot for arm64? I don't see we ever created 64-bit U-Boot for ppc64.
In ARMv8 it's not possible to change the register width at an exception level (i.e. you can't change 64->32 or vice-versa), and lower exception levels cannot be wider (so if your code at EL3 is 32-bit, you cannot run 64-bit code at EL3, EL2, EL1, or EL0).
Therefore you need a purely 64-bit path from EL3 to EL2 or EL1N in order to boot a 64-bit kernel, so the bootloader needs to be 64-bit.
Mark.
participants (5)
-
Bin Meng -
Hanna Hawa -
Mark Rutland -
Simon Glass -
Thierry Reding