[U-Boot] 64Bit device tree compilation

[U-Boot] 64Bit device tree compilation

[Hanna Hawa]

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

[U-Boot] 64Bit device tree compilation

[Simon Glass]

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

[U-Boot] 64Bit device tree compilation

[Thierry Reding]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150319/e58e4483/attachment.sig>

[U-Boot] 64Bit device tree compilation

[Bin Meng]

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

[U-Boot] 64Bit device tree compilation

[Mark Rutland]

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.