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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 31-03-16 21:22, Hans de Goede wrote:
> Hi,
>
> On 31-03-16 21:15, Alexander Graf wrote:
>>
>>
>>> Am 31.03.2016 um 20:53 schrieb Hans de Goede <hdegoede@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.

p.s.

This patchset broke every other sunxi board! 2 very minor issues, already
fixed up in my tree. I always build all sunxi builds before sending
out a pull-req :)

Regards,

Hans