[U-Boot] [PATCH 0/6] arm64: Pine64 fixes and updates
André Przywara
andre.przywara at arm.com
Thu May 5 00:36:58 CEST 2016
On 04/05/16 23:15, Peter Robinson wrote:
> On Wed, May 4, 2016 at 11:05 PM, André Przywara <andre.przywara at arm.com> wrote:
>> On 04/05/16 22:53, Peter Robinson wrote:
>>> On Wed, May 4, 2016 at 10:15 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>>>> This series improves the Pine64 support.
>>>> The first patch fixes a build break, see details in the commit message.
>>>> Patch 2/6 reverts a no longer needed memory reservation, as the firmware
>>>> bits that used to live in DRAM now can reside in SRAM.
>>>> To allow U-Boot to be easily loaded by Allwinner's boot0 loader, patch
>>>> 3/6 reserves some space at the beginning of the image to (optionally)
>>>> fit in a header required by boot0.
>>>> Patch 4/6 adjusts the default load addresses in the environment to
>>>> meet the arm64 requirements (especially the kernel load address).
>>>> The device tree files included in the original Pine64 commit are
>>>> outdated, so patch 5/6 replaces some with more mature versions and also
>>>> adjusts the naming to match other sunxi boards.
>>>> The final patch renames the _defconfig file to get rid of the _plus_
>>>> insert.
>>>>
>>>> Please review, comment and apply, if possible.
>>>
>>> I'll test this tomorrow on my 1Gb Plus board,
>>
>> Thanks!
>>
>>> it would be good to have
>>> a README.pine64 with details about where to get the ATF firmware from
>>> and how to use it with this u-boot to get a booted device something
>>> similar to README.odroid
>>
>> Yes, I am on the documentation.
>
> Cool, btw what's the redistribution license on the ATF firmware, is it
> redistributable by distributions (like other firmware),
ATF is the "ARM Trusted Firmware", which is a proper OpenSource project
under a BSD license. The home is on github [1].
In the moment I am working with an Allwinner provided codebase and
having fixes on top, but I removed quite some useless code already and
started with a proper upstream port.
I will push the repository onto my github fork [2] (once I manage to get
off mail and IRC ;-)
> is it usable on all devices with a AllWinner A64?
I would think so. A good part of the code in there is about the cores
and the GIC: so pretty generic. In the moment all power management is on
a SoC level - but in the future we might drive the PMIC from ATF as
well, which would potentially differ between boards.
> Will it be needed with the proper SPL you mention below?
Yes, the most prominent feature that ATF provides on the Pine64 is the
PSCI service. ATF is actually the PSCI reference implementation, so it
does the right thing and is more advanced than what U-Boot provides, for
instance.
Also ATF cares about some errata fixups for various cores, some of them
can only be provided by firmware (in EL3).
So I think ATF should take over the actual firmware load that U-Boot
carried in the past for various boards as well.
For the Pine64 I would very much like U-Boot to be just a boot loader.
>> As we lack DRAM initialization at the moment, I use a tool to assemble
>> all the firmware bits together with boot0 into an image.
>> This should supersede Alex' pine64_image tool.
>
> OK, I've been using Alex's tool to date.
>
>> Shall this tool (written in C) also be part of U-Boot, say in the tools
>> directory? Or is this better pushed into the sunxi-tools repository?
>> Eventually with a proper SPL we will not need it anymore, so I refrained
>> from pushing it into U-Boot for now.
>
> TBH I've no idea what's best here, I suppose it depends on timeframes,
> it might just be useful to put it in a git repo somewhere and
> reference it in a readme, once there's patches that have the proper
> SPL update the readme as part of it.
Yes, expect it to appear on [3] anytime soon.
Cheers,
Andre.
[1] https://github.com/ARM-software/arm-trusted-firmware
[2] https://github.com/apritzel/arm-trusted-firmware
[3] https://github.com/apritzel/pine64
>>>
>>>> P.S. tools/buildman/README was TL;DR, so I just tested Pine64 and
>>>> Bananapi compilation. If someone with a working buildman setup could
>>>> test this for build regressions, I'd be grateful.
>>>>
>>>> Andre Przywara (6):
>>>> arm/arm64: Move barrier instructions into separate header
>>>> Revert "sunxi: Reserve ATF memory space on A64"
>>>> arm64: sunxi: reserve space for boot0 header
>>>> arm64: sunxi: adjust default load addresses
>>>> arm64: Pine64: update FDT files
>>>> Pine64: rename defconfig
>>>>
>>>> arch/arm/cpu/armv8/start.S | 3 +
>>>> arch/arm/dts/Makefile | 3 +-
>>>> arch/arm/dts/a64.dtsi | 564 --------------------------
>>>> arch/arm/dts/pine64.dts | 62 ---
>>>> arch/arm/dts/pine64_common.dtsi | 76 ----
>>>> arch/arm/dts/pine64_plus.dts | 63 ---
>>>> arch/arm/dts/sun50i-a64-pine64-common.dtsi | 80 ++++
>>>> arch/arm/dts/sun50i-a64-pine64-plus.dts | 59 +++
>>>> arch/arm/dts/sun50i-a64-pine64.dts | 58 +++
>>>> arch/arm/dts/sun50i-a64.dtsi | 624 +++++++++++++++++++++++++++++
>>>> arch/arm/include/asm/armv7.h | 21 +-
>>>> arch/arm/include/asm/barriers.h | 44 ++
>>>> arch/arm/mach-sunxi/dram_helpers.c | 2 +-
>>>> board/sunxi/board.c | 9 -
>>>> configs/pine64_defconfig | 20 +
>>>> configs/pine64_plus_defconfig | 20 -
>>>> include/configs/sunxi-common.h | 18 +
>>>> 17 files changed, 910 insertions(+), 816 deletions(-)
>>>> delete mode 100644 arch/arm/dts/a64.dtsi
>>>> delete mode 100644 arch/arm/dts/pine64.dts
>>>> delete mode 100644 arch/arm/dts/pine64_common.dtsi
>>>> delete mode 100644 arch/arm/dts/pine64_plus.dts
>>>> create mode 100644 arch/arm/dts/sun50i-a64-pine64-common.dtsi
>>>> create mode 100644 arch/arm/dts/sun50i-a64-pine64-plus.dts
>>>> create mode 100644 arch/arm/dts/sun50i-a64-pine64.dts
>>>> create mode 100644 arch/arm/dts/sun50i-a64.dtsi
>>>> create mode 100644 arch/arm/include/asm/barriers.h
>>>> create mode 100644 configs/pine64_defconfig
>>>> delete mode 100644 configs/pine64_plus_defconfig
>>>>
>>>> --
>>>> 2.7.3
>>>>
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot at lists.denx.de
>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>
>
More information about the U-Boot
mailing list