[U-Boot] VEXPRESS64 ARMv8 U-Boot maintenance

[U-Boot] VEXPRESS64 ARMv8 U-Boot maintenance

[Linus Walleij]

Hi folks
(David & Steve listed as AArch64/v8 maintainers),

are you actively maintaining and reviewing ARM64 board
patches?

I am working on support for the ARM Juno Development
Platform real hardware, which is now up and running on my
desk. I will add this board with myself as maintainer.

But who takes care of the code in arch/arm/cpu/armv8?

I have some questions about the rendez-vous code in the
armv8 start.S file, as if two CPUs (master & slave) would come
running into U-Boot, which is not what ARM Trusted Firmware
does, it arrives only on the master CPU. Can any of you explain
why that code is there?

Else I will start looking at it and add myself as maintainer for
this.

Please also have a look at my patches to the Semihosting code:
http://patchwork.ozlabs.org/patch/412628/
http://patchwork.ozlabs.org/patch/412629/
http://patchwork.ozlabs.org/patch/412630/

Yours,
Linus Walleij

[U-Boot] VEXPRESS64 ARMv8 U-Boot maintenance

[Tom Rini]

On Thu, Dec 11, 2014 at 10:48:43AM +0100, Linus Walleij wrote:

> Hi folks
> (David & Steve listed as AArch64/v8 maintainers),
> 
> are you actively maintaining and reviewing ARM64 board
> patches?
> 
> I am working on support for the ARM Juno Development
> Platform real hardware, which is now up and running on my
> desk. I will add this board with myself as maintainer.

Oh good.  I was hoping someone would get a chance to do this.  I had a
few more ideas about what might have been needed but haven't been able
to cycle back around to hooking mine up and playing again.

> But who takes care of the code in arch/arm/cpu/armv8?

Currently it falls under Albert's care as the overall core ARM
maintainer.

> I have some questions about the rendez-vous code in the
> armv8 start.S file, as if two CPUs (master & slave) would come
> running into U-Boot, which is not what ARM Trusted Firmware
> does, it arrives only on the master CPU. Can any of you explain
> why that code is there?
> 
> Else I will start looking at it and add myself as maintainer for
> this.
> 
> Please also have a look at my patches to the Semihosting code:
> http://patchwork.ozlabs.org/patch/412628/
> http://patchwork.ozlabs.org/patch/412629/
> http://patchwork.ozlabs.org/patch/412630/

I think the overall answer here is that as the code base and
implementation evolves everywhere, we'll need some adjustments to match
up.  Please make sure to keep York Sun in the loop too as Freescale is
active in this area as well (and the other Freescale folks too as they
transition from multi-core PowerPC to multi-core ARMv8 :)).  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141212/2fff8a6c/attachment.pgp>

[U-Boot] VEXPRESS64 ARMv8 U-Boot maintenance

[Steve Rae]

On 14-12-11 01:48 AM, Linus Walleij wrote:
> Hi folks
> (David & Steve listed as AArch64/v8 maintainers),
>
> are you actively maintaining and reviewing ARM64 board
> patches?
Sadly, no.
If you would take over being maintainer for the "vexpress_aemv8a_semi" 
board, that would be appreciated.
Thanks, Steve
>
> I am working on support for the ARM Juno Development
> Platform real hardware, which is now up and running on my
> desk. I will add this board with myself as maintainer.
>
> But who takes care of the code in arch/arm/cpu/armv8?
>
> I have some questions about the rendez-vous code in the
> armv8 start.S file, as if two CPUs (master & slave) would come
> running into U-Boot, which is not what ARM Trusted Firmware
> does, it arrives only on the master CPU. Can any of you explain
> why that code is there?
>
> Else I will start looking at it and add myself as maintainer for
> this.
>
> Please also have a look at my patches to the Semihosting code:
> http://patchwork.ozlabs.org/patch/412628/
> http://patchwork.ozlabs.org/patch/412629/
> http://patchwork.ozlabs.org/patch/412630/
I will look at these -- Thanks, Steve
>
> Yours,
> Linus Walleij
>