Peter, Is F23 aarch64 supporting either HiKey or Dragonboard?

On Fri, Sep 25, 2015 at 11:17 AM, Clive Messer <clive.m.messer(a)gmail.com&gt; wrote: > 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 arm(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm

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)?

On Wed, Sep 14, 2016 at 6:00 PM, Ziqian SUN(zsun) <zsun(a)fedoraproject.org&gt; wrote: > 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. > 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(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

Hi Robert, On 01/18/2017 09:02 PM, Robert Moskowitz wrote: > 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... 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/ar... 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/dtb... 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/... 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