[U-Boot] [PATCH 0/6] Add Pine64 support

[Hans de Goede]

Hi,

On 31-03-16 21:15, Alexander Graf wrote:
>
>
>> Am 31.03.2016 um 20:53 schrieb Hans de Goede <hdegoede at redhat.com>:
>>
>> Hi,
>>
>>> On 29-03-16 18:08, Alexander Graf wrote:
>>>
>>>
>>>> On 29.03.16 17:45, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>>> On 03/29/2016 05:29 PM, Alexander Graf wrote:
>>>>> The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64
>>>>> SoC.
>>>>> This SoC can run AArch64 code, so this patch set lifts all arm version
>>>>> indepenent sunxi code into a mach directory and builds the A64 code
>>>>> as armv8 (aarch64) code.
>>>>>
>>>>> With these patches applied, I can successfully boot my 1GB Pine64+ board
>>>>> with an openSUSE EFI image.
>>>>
>>>> Can you provide some quick instructions on how to test this ? Bonus
>>>> point for a link to a boot0.bin which I can dd to a sdcard and use
>>>> with a u-boot.bin build with these patches.
>>>
>>> Sure. Grab these all the files in this directory:
>>>
>>>    http://csgraf.de/agraf/pine64
>>>
>>> Then do
>>>
>>>    $ gcc pine64_image.c -o pine64_image
>>>    $ cat bl31.bin <u-boot-dir>/u-boot.bin > bl31uboot.bin
>>>    $ ./pine64_image scp.bin bl31uboot.bin u-boot.img
>>>    $ dd if=boot0.bin of=/dev/mmcblk0 seek=16
>>>    $ dd if=u-boot.img of=/dev/mmcblk0 seek=80
>>>
>>> That should give you a working system. The scp.bin and boot0.bin are
>>> from the Allwinner binary distribution. ATF (bl31.bin) is built from
>>> these sources:
>>>
>>>
>>> https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/firmware-pine64
>>>
>>>
>>> Enjoy,
>>
>> Thanks, works like a charm.
>>
>> I've applied the entire series to my tree, except for
>> "[PATCH 3/6] arm: Allow u32 as addrs for readX/writeX"
>> instead I've added 2 extra casts to your
>> "[PATCH 4/6] sunxi: Explicitly cast u32 pointer conversions"
>> patch, which is enough to build warning free for me.
>>
>> I still have some other patches to process, I'll send a pull-req
>> tomorrow morning.
>
> Thanks :)
>
>>
>> Note I've squashed the following fixes into
>> "[PATCH 5/6] sunxi: Add support for Allwinner A64 SoCs" :
>>
>> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> @@ -352,10 +352,10 @@ struct sunxi_ccm_reg {
>>
>> #if defined(CONFIG_MACH_SUN50I)
>> #define MBUS_CLK_DEFAULT               0x81000002 /* PLL6x2 / 3 */
>> -#elif !defined(CONFIG_MACH_SUN8I)
>> -#define MBUS_CLK_DEFAULT           0x81000001 /* PLL6 / 2 */
>> -#else
>> +#elif defined(CONFIG_MACH_SUN8I)
>> #define MBUS_CLK_DEFAULT               0x81000003 /* PLL6 / 4 */
>> +#else
>> +#define MBUS_CLK_DEFAULT             0x81000001 /* PLL6 / 2 */
>> #endif
>> #define MBUS_CLK_GATE                  (0x1 << 31)
>>
>>
>> --- a/arch/arm/include/asm/system.h
>> +++ b/arch/arm/include/asm/system.h
>> @@ -92,12 +92,6 @@ static inline unsigned long read_mpidr(void)
>>
>> #define BSP_COREID     0
>>
>> -static inline void sdelay(unsigned long n)
>> -{
>> -       int i;
>> -       for (i = 0; i < n; i++) asm volatile("");
>> -}
>> -
>
> How did you manage to build without sdelay? The sun6i clock code used it, no? Or is something there guarded with CONFIG_SPL_BUILD?

The code in question is #ifdef CONFIG_SPL_BUILD I guess we will need to
fix this somehow when we get SPL support, I'm pretty sure the above
is not the right solution.

Regards,

Hans