On 02/22/2016 05:38 PM, Scott Wood wrote: > On Wed, 2016-02-10 at 05:20 +0000, york sun wrote: >> On 02/09/2016 09:10 PM, Scott Wood wrote: >>> On Wed, 2016-02-10 at 02:30 +0000, york sun wrote: >> >> <snip> >> >>>> >>>> Aneesh and Scott, >>>> >>>> I need to revisit this patch. Would it be better to change it as below? >>>> >>>> +#if defined(CONFIG_PHYS_64BIT) && !defined(CONFIG_ARM64) >>>> +typedef unsigned long long dma_addr_t; >>>> +typedef unsigned long long phys_addr_t; >>>> +typedef unsigned long long phys_size_t; >>>> +#else >>>> +/* DMA addresses are 32-bits wide */ >>>> typedef u32 dma_addr_t; >>>> - >>>> typedef unsigned long phys_addr_t; >>>> typedef unsigned long phys_size_t; >>>> +#endif >>>> >>>> I am debugging another patch and found changing phys_addr_t makes some >>>> trouble >>>> for ARM64, especially to mix with ulong. >>> >>> What sort of trouble is it causing? And why would you mix it with ulong? >>> >> >> I am debugging this patch http://patchwork.ozlabs.org/patch/514590/. >> ulong is used a lot for image related calls. I tried to change to >> phys_addr_t, >> but only buried myself even deeper. Basically I am battling on three sides >> >> 1. All 32-bit SoCs should continue to work without using 64-bit variables >> for >> addresses. >> 2. 64-bit SoCs such as ARMv8 will support FIT with addresses beyond 32 bits. >> 3. Host tool such as mkimage should work on both 32- and 64-bit host OS. >> >> Any suggestion is welcomed. > > Is there any situation where we'd support loading images to addresses that > don't fit in ulong? Why do you need to switch it to phys_addr_t? > > mkimage is another matter -- since it could be generating images for any > target, it should be using a fixed 64-bit type for internally representing > target addresses. Not ulong and not phys_addr_t (which shouldn't exist in > userspace). > > In any case, the answer isn't to undo this patch or make an exception for > ARM64. >
Scott, I moved away from this thread. I am not going to revert/undo this patch. I have sent a RFC set "Enable FIT image to be loaded beyond 32-bit space". York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
