Re: Rock64 support for F28?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 9, 2018 at 2:40 AM, Jonathan Vaughn <jonathan@xxxxxxxxxxxxx> wrote:
> I see a few months ago in the mailing list that support was brought up (in
> the context of F27) and it was mentioned that improving support for
> Rockchips devices in general was intended for F28.

Yes, I did intend on doing that, I ran into a number of problems and
also purely just ran out of time.

> It doesn't appear that fedora-arm-installer currently supports the Rock64
> board as far as I can tell.

That is correct and the Rock64 particularly is different to the
Rockchips support above. The Rock64 device is not supported in
upstream u-boot which is what we ship and for a device to be
classified as fully supported by Fedora so even when the improvement
in Rockchips support lands (which I'm hoping I will finish off in
F-29, assistance would help) it's currently unlikely the Rock64 will
be in that list.

> I'm trying to figure out how to add support by adding to
> /usr/share/arm-image-installer/boards.d and socs.d, as well as solving the
> lack of appropriate uboot in /usr/share/uboot for Rock64.

That's two different problems and there's a bunch of other stuff that
is actually in there.

> I flashed (and tested successfully) a community built Debian Stretch image
> and by comparing it's partition layout and some information from OpenSUSE I
> can guess at what some of it should be, but I'm not entirely sure how to
> make the appropriate files in socs.d, boards.d, and what all is needed in
> uboot ...

Most of what you have below is interesting but most probably won't
going into a-i-i, we don't currently and personally I really not sure
i want to go the route of moving around partitions and changing
partitioning schemes on the fly there.

> Debian Stretch image that boots :
> https://github.com/ayufan-rock64/linux-build/releases/download/0.7.8/stretch-minimal-rock64-0.7.8-1061-arm64.img.xz
> U-boot used in the above build :
> https://github.com/ayufan-rock64/linux-u-boot
> OpenSUSE info : https://en.opensuse.org/HCL:Rock64
>
> working stretch partition layout :
> # gdisk -l /dev/sdc
> GPT fdisk (gdisk) version 1.0.4
>
> Partition table scan:
>   MBR: protective
>   BSD: not present
>   APM: not present
>   GPT: present
>
> Found valid GPT with protective MBR; using GPT.
> Disk /dev/sdc: 62333952 sectors, 29.7 GiB
> Model: Storage Device
> Sector size (logical/physical): 512/512 bytes
> Disk identifier (GUID): 9CFDF7D8-766C-43DE-9354-57097D428E8F
> Partition table holds up to 128 entries
> Main partition table begins at sector 2 and ends at sector 33
> First usable sector is 34, last usable sector is 62333918
> Partitions will be aligned on 64-sector boundaries
> Total free space is 30 sectors (15.0 KiB)
>
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1              64            8063   3.9 MiB     8300  loader1
>    2            8064            8191   64.0 KiB    8300  reserved1
>    3            8192           16383   4.0 MiB     8300  reserved2
>    4           16384           24575   4.0 MiB     8300  loader2
>    5           24576           32767   4.0 MiB     8300  atf
>    6           32768          262143   112.0 MiB   0700  boot
>    7          262144        62333918   29.6 GiB    8300  root
>
> loader1 (partition 1) is the SPL, loader2 (partition 4) is the U-Boot. atf
> (partition 5) per OpenSUSE is apparently some kind of "trust" image.

ATF is Arm Trusted Firmware, it's a requirement of ARMv8 / aarch64.
It's a core part of the ARM architecture and handles a number of
things including the PSCI which is what handles things such as
secondary CPU startup etc.

> The reserved partitions (partitions 2 and 3) seem to just be all nulls.
>
> The boot partition (partition 6) has extlinux/extlinux.conf apparently as
> well as 'System Volume Information' (guessing that the origin of that
> partition was built on Windows), and partition 7 is of course regular old
> Linux filesystem.

Being Debian I very much doubt that TBH

> I'm not sure how fedora-arm-installer decides to partition things, it wasn't

It doesn't, only thing it does related to partitions is to optionally
grow the root partitions out to the full size of the destination
storage.

> obvious from socs.d/boards.d, so I'm not sure how to ensure that when
> creating the soc/board scripts that the correct layout is maintained. From
> glancing at the source code for fedora-arm-installer it seems like it just
> extracts the image onto the media and assumes the layout based on what was
> in the image, which might present a problem if the unified AArch64 image has
> only 3 partitions? Unless it would be expected that Fedora would have it's
> own build of uboot that would ensure things didn't need all those other
> partitions ?
>
> Anyways, I'm happy to either figure this out on my own if you can point me
> in the right direction or if you already have some WIP that needs a
> volunteer to test it, to do be your guinea pig.

So all the of the above is interesting but I'm not sure we actually
need to put all the bits into a series of partitions. Generally a lot
of the above appears to be based upon the way Android does this stuff.

Rockchips actually some really good docs on their boot process, a few
bits are a little out of date based on improvements in upstream U-Boot
but it's a very useful starting point:

http://opensource.rock-chips.com/wiki_Boot_option

>From there we should be able to dd out the U-Boot/ATF stack to an
offset and it should just work. The bit that I've had issues with is
around the upstream ATF working on the SoCs

Peter
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx/message/WUS2SCZGD3JOHLQNZOYH45KFOJBLJEL6/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux