[fedora-arm] F23 aarch64 support for HiKey and Dragonboard?

[Clive Messer]

Peter,

Is F23 aarch64 supporting either HiKey or Dragonboard?

Clive

[Peter Robinson]

Post by Clive Messer
Peter,
Is F23 aarch64 supporting either HiKey or Dragonboard?

HiKey should boot with 4.2 (what's in F-23) with MMC, usb looks
terrible which isn't particularly useful, in theory wireless is
upstream but I've not had a chance to get that far as I'm awaiting a
decent UART [1] for easy debug of the board, at the moment I've not
enabled dragonboard (QCOM) but it's on my list for next week, it's
confirmed that HDMI has issues but everything else should work. The
QCom stuff has weird bootloaders (not uboot or uEFI) so YMMV.

[1] http://www.seeedstudio.com/depot/96Boards-UART-p-2525.html?ref=newInBazaar

[Clive Messer]

Post by Peter Robinson
HiKey should boot with 4.2 (what's in F-23) with MMC, usb looks
terrible which isn't particularly useful, in theory wireless is
upstream but I've not had a chance to get that far as I'm awaiting a
decent UART [1] for easy debug of the board, at the moment I've not
enabled dragonboard (QCOM) but it's on my list for next week, it's
confirmed that HDMI has issues but everything else should work. The
QCom stuff has weird bootloaders (not uboot or uEFI) so YMMV.

Thanks for the info!

I'm going to translate your answer to a simple, "not out of the box", 
for the sake of the person who asked me the question, which caused me to
ask you the question. He's a user, rather than a developer. ;)

Clive

[Ziqian SUN(zsun)]

Sorry for reply on ancient mail.
I see that neither HiKey nor DragonBoard is marked in the wiki[1]. So I
want to know what's the support status of Hikey Board?

And I see usually we ship ISO for aarch64, while Hikey and Dragon Board
usually needs a img. So if supported, any hints on how I can install it
on my Hikey (or even, how can I convert the ISO to a img file)?

Thanks.

[1] https://fedoraproject.org/wiki/Architectures/AArch64/F24/Installation

Post by Peter Robinson

Post by Clive Messer
Peter,
Is F23 aarch64 supporting either HiKey or Dragonboard?

HiKey should boot with 4.2 (what's in F-23) with MMC, usb looks
terrible which isn't particularly useful, in theory wireless is
upstream but I've not had a chance to get that far as I'm awaiting a
decent UART [1] for easy debug of the board, at the moment I've not
enabled dragonboard (QCOM) but it's on my list for next week, it's
confirmed that HDMI has issues but everything else should work. The
QCom stuff has weird bootloaders (not uboot or uEFI) so YMMV.
[1] http://www.seeedstudio.com/depot/96Boards-UART-p-2525.html?ref=newInBazaar
_______________________________________________
arm mailing list
https://admin.fedoraproject.org/mailman/listinfo/arm

[William Cohen]

Post by Ziqian SUN(zsun)
Sorry for reply on ancient mail.
I see that neither HiKey nor DragonBoard is marked in the wiki[1]. So I want to know what's the support status of Hikey Board?
And I see usually we ship ISO for aarch64, while Hikey and Dragon Board usually needs a img. So if supported, any hints on how I can install it on my Hikey (or even, how can I convert the ISO to a img file)?
Thanks.
[1] https://fedoraproject.org/wiki/Architectures/AArch64/F24/Installation

Hi,

The dragonboard uses a different bootloader (little kernel) than was is expected for Fedora aarch64 installation. There is a Fedora 23 remix that runs off of a sd card for the dragonboard 410c:

https://dmarlin.fedorapeople.org/fedora-arm/aarch64/README.Linaro-F23-remix-lxde

-Will

Post by Ziqian SUN(zsun)

Post by Peter Robinson

Post by Clive Messer
Peter,
Is F23 aarch64 supporting either HiKey or Dragonboard?

HiKey should boot with 4.2 (what's in F-23) with MMC, usb looks
terrible which isn't particularly useful, in theory wireless is
upstream but I've not had a chance to get that far as I'm awaiting a
decent UART [1] for easy debug of the board, at the moment I've not
enabled dragonboard (QCOM) but it's on my list for next week, it's
confirmed that HDMI has issues but everything else should work. The
QCom stuff has weird bootloaders (not uboot or uEFI) so YMMV.
[1] http://www.seeedstudio.com/depot/96Boards-UART-p-2525.html?ref=newInBazaar
_______________________________________________
arm mailing list
https://admin.fedoraproject.org/mailman/listinfo/arm

[Peter Robinson]

On Wed, Sep 14, 2016 at 6:00 PM, Ziqian SUN(zsun)

Post by Ziqian SUN(zsun)
Sorry for reply on ancient mail.
I see that neither HiKey nor DragonBoard is marked in the wiki[1]. So I want
to know what's the support status of Hikey Board?

HiKey with the uEFI firmware should boot fine with 4.7/4.8 kernels,
although due to the weird partitioning needed to deal with firmware
you're probably better off running it on a mSD/USB stick. Dragonboard
has support enabled in the kernel but I've had little feedback on it,
and it also needs firmware we can't (yet?) redistribute.

Post by Ziqian SUN(zsun)
And I see usually we ship ISO for aarch64, while Hikey and Dragon Board
usually needs a img. So if supported, any hints on how I can install it on
my Hikey (or even, how can I convert the ISO to a img file)?

Disk images are being worked on. I'm getting there on them but they're
one of MANY things on my ToDo list and vying for my time.

[Ziqian SUN(zsun)]

Post by Peter Robinson
On Wed, Sep 14, 2016 at 6:00 PM, Ziqian SUN(zsun)

Post by Ziqian SUN(zsun)
Sorry for reply on ancient mail.
I see that neither HiKey nor DragonBoard is marked in the wiki[1]. So I want
to know what's the support status of Hikey Board?

HiKey with the uEFI firmware should boot fine with 4.7/4.8 kernels,
although due to the weird partitioning needed to deal with firmware
you're probably better off running it on a mSD/USB stick. Dragonboard
has support enabled in the kernel but I've had little feedback on it,
and it also needs firmware we can't (yet?) redistribute.

Post by Ziqian SUN(zsun)
And I see usually we ship ISO for aarch64, while Hikey and Dragon Board
usually needs a img. So if supported, any hints on how I can install it on
my Hikey (or even, how can I convert the ISO to a img file)?

Disk images are being worked on. I'm getting there on them but they're
one of MANY things on my ToDo list and vying for my time.

Thanks Peter.
Now I'm trying to install to a img using qemu. Later I will update the
kernel and try to dd it onto a mSD to see if it works on Hikey Board
(without the UART board). If it worked, I'll update to the list.

[Robert Moskowitz]

There is a local (Detroit) IoT meeting showcasing the Dragonboard 410c.

What is the status of support on it now?

Want to know to what degree I try to go to the meeting...

thanks!

Bob

Post by Peter Robinson
On Wed, Sep 14, 2016 at 6:00 PM, Ziqian SUN(zsun)

Post by Ziqian SUN(zsun)
Sorry for reply on ancient mail.
I see that neither HiKey nor DragonBoard is marked in the wiki[1]. So I want
to know what's the support status of Hikey Board?

HiKey with the uEFI firmware should boot fine with 4.7/4.8 kernels,
although due to the weird partitioning needed to deal with firmware
you're probably better off running it on a mSD/USB stick. Dragonboard
has support enabled in the kernel but I've had little feedback on it,
and it also needs firmware we can't (yet?) redistribute.

Post by Ziqian SUN(zsun)
And I see usually we ship ISO for aarch64, while Hikey and Dragon Board
usually needs a img. So if supported, any hints on how I can install it on
my Hikey (or even, how can I convert the ISO to a img file)?

Disk images are being worked on. I'm getting there on them but they're
one of MANY things on my ToDo list and vying for my time.
_______________________________________________
arm mailing list

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email

[Christopher Covington]

Hi Robert,

Post by Robert Moskowitz
There is a local (Detroit) IoT meeting showcasing the Dragonboard 410c.
What is the status of support on it now?
Want to know to what degree I try to go to the meeting...

It looks like the Dragonboard 410c has an APQ8016 chip, which is basically
the MSM8916 with no modem, so broadly equivalent to applications processor
software.

There has been a lot of work to get those and other Qualcomm Technologies
chips supported in the upstream Linux kernel, but some of it has only
been finished recently, for example with display support for 8016 landing
in 4.9:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bd3af15a4e4d528bb0a0eea1daca0b818baa9fd8

A quick look at Fedora kernel configuration options makes me worried that
the Fedora 25 kernel would not work on the DB410c out of the box.

# CONFIG_MSM_GCC_8916 is not set
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/baseconfig/arm/arm64/CONFIG_MSM_GCC_8916

GCC is the Global Clock Controller in this context. I have no idea how
it works. It sounds important, but perhaps it's only required for
run-time changes to the clocks, which may or may not be needed for basic
functionality. Basic functionality may be available by coasting along on
the clock setup from firmware. If somebody like Stephen or Andy who knows
this stuff wants to tell me what to change in the configuration I'd be
happy to prepare the patch, although I only have 8074 and 8064 boards
and not 8016 myself for testing.

One of the barriers to distribution support of these Q mobile devices has
been the firmware/bootloader. The devices come with Little Kernel (LK) as
the primary bootloader. I've heard that it requires special lines in the
device tree file, but since these aren't useful to Linux, they aren't
allowed to be kept in the device tree source on kernel.org. So if you want
to use upstream device tree files, you need to run a tool to insert the
special bootloader-specific lines before or while creating the device tree
blob.

https://source.codeaurora.org/quic/la/device/qcom/common/tree/dtbtool/dtbtool.txt?h=l_master
https://source.codeaurora.org/quic/kernel/skales/tree/dtbTool

Once that's complete, the kernel, device-tree-with-bootloader-extras, and
initramfs must be packaged into the Android fastboot/bootimg binary image
format:

https://android.googlesource.com/platform/system/core/+/master/mkbootimg/bootimg.h#66
https://source.codeaurora.org/quic/kernel/skales/tree/mkbootimg

Fedora doesn't support this format at the moment, and I think some or most
developers favor putting a familiar bootloader in the bootimg as a
compatibility shim. As far as I know, that's yet another unfinished project.

If anyone knows better, please correct me if I got any of this wrong, but
hopefully this is a useful starting point.

Regards,
Cov

[Robert Moskowitz]

Christopher,

Thank you

I may print this off and bring it to the meeting to highlight the
challenges some of these boards present.

Robert

Post by Christopher Covington
Hi Robert,

Post by Robert Moskowitz
There is a local (Detroit) IoT meeting showcasing the Dragonboard 410c.
What is the status of support on it now?
Want to know to what degree I try to go to the meeting...

It looks like the Dragonboard 410c has an APQ8016 chip, which is basically
the MSM8916 with no modem, so broadly equivalent to applications processor
software.
There has been a lot of work to get those and other Qualcomm Technologies
chips supported in the upstream Linux kernel, but some of it has only
been finished recently, for example with display support for 8016 landing
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bd3af15a4e4d528bb0a0eea1daca0b818baa9fd8
A quick look at Fedora kernel configuration options makes me worried that
the Fedora 25 kernel would not work on the DB410c out of the box.
# CONFIG_MSM_GCC_8916 is not set
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/baseconfig/arm/arm64/CONFIG_MSM_GCC_8916
GCC is the Global Clock Controller in this context. I have no idea how
it works. It sounds important, but perhaps it's only required for
run-time changes to the clocks, which may or may not be needed for basic
functionality. Basic functionality may be available by coasting along on
the clock setup from firmware. If somebody like Stephen or Andy who knows
this stuff wants to tell me what to change in the configuration I'd be
happy to prepare the patch, although I only have 8074 and 8064 boards
and not 8016 myself for testing.
One of the barriers to distribution support of these Q mobile devices has
been the firmware/bootloader. The devices come with Little Kernel (LK) as
the primary bootloader. I've heard that it requires special lines in the
device tree file, but since these aren't useful to Linux, they aren't
allowed to be kept in the device tree source on kernel.org. So if you want
to use upstream device tree files, you need to run a tool to insert the
special bootloader-specific lines before or while creating the device tree
blob.
https://source.codeaurora.org/quic/la/device/qcom/common/tree/dtbtool/dtbtool.txt?h=l_master
https://source.codeaurora.org/quic/kernel/skales/tree/dtbTool
Once that's complete, the kernel, device-tree-with-bootloader-extras, and
initramfs must be packaged into the Android fastboot/bootimg binary image
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/bootimg.h#66
https://source.codeaurora.org/quic/kernel/skales/tree/mkbootimg
Fedora doesn't support this format at the moment, and I think some or most
developers favor putting a familiar bootloader in the bootimg as a
compatibility shim. As far as I know, that's yet another unfinished project.
If anyone knows better, please correct me if I got any of this wrong, but
hopefully this is a useful starting point.
Regards,
Cov

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

[Peter Robinson]

On Fri, Jan 20, 2017 at 5:06 PM, Christopher Covington

Post by Christopher Covington
Hi Robert,

Post by Robert Moskowitz
There is a local (Detroit) IoT meeting showcasing the Dragonboard 410c.
What is the status of support on it now?
Want to know to what degree I try to go to the meeting...

It looks like the Dragonboard 410c has an APQ8016 chip, which is basically
the MSM8916 with no modem, so broadly equivalent to applications processor
software.
There has been a lot of work to get those and other Qualcomm Technologies
chips supported in the upstream Linux kernel, but some of it has only
been finished recently, for example with display support for 8016 landing
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bd3af15a4e4d528bb0a0eea1daca0b818baa9fd8
A quick look at Fedora kernel configuration options makes me worried that
the Fedora 25 kernel would not work on the DB410c out of the box.
# CONFIG_MSM_GCC_8916 is not set
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/baseconfig/arm/arm64/CONFIG_MSM_GCC_8916
GCC is the Global Clock Controller in this context. I have no idea how
it works. It sounds important, but perhaps it's only required for
run-time changes to the clocks, which may or may not be needed for basic
functionality. Basic functionality may be available by coasting along on
the clock setup from firmware. If somebody like Stephen or Andy who knows
this stuff wants to tell me what to change in the configuration I'd be
happy to prepare the patch, although I only have 8074 and 8064 boards
and not 8016 myself for testing.
One of the barriers to distribution support of these Q mobile devices has
been the firmware/bootloader. The devices come with Little Kernel (LK) as
the primary bootloader. I've heard that it requires special lines in the
device tree file, but since these aren't useful to Linux, they aren't
allowed to be kept in the device tree source on kernel.org. So if you want
to use upstream device tree files, you need to run a tool to insert the
special bootloader-specific lines before or while creating the device tree
blob.
https://source.codeaurora.org/quic/la/device/qcom/common/tree/dtbtool/dtbtool.txt?h=l_master
https://source.codeaurora.org/quic/kernel/skales/tree/dtbTool
Once that's complete, the kernel, device-tree-with-bootloader-extras, and
initramfs must be packaged into the Android fastboot/bootimg binary image
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/bootimg.h#66
https://source.codeaurora.org/quic/kernel/skales/tree/mkbootimg
Fedora doesn't support this format at the moment, and I think some or most
developers favor putting a familiar bootloader in the bootimg as a
compatibility shim. As far as I know, that's yet another unfinished project.
If anyone knows better, please correct me if I got any of this wrong, but
hopefully this is a useful starting point.

That's pretty much correct. The kernel config was a best guess based
on other people's configs from me. I've not tested it because I've not
had the time to smash my head against the bootloader garbage so
patches for the kernel stuff are welcome. There's also the little
problem of it requiring non redistributable binary blobs. This was
suppose to have been fixed, or at least improved, but the last time I
went to get them there was still a click through legal agreement so I
left and moved on to something else.

Peter
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to