Good day all,
This weeks Fedora ARM status meeting will take place today (Wednesday Aug 8th) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
Current items on the agenda:
1) F18 - Mass rebuild status
2) Mass rebuild - statistical analysis of time taken overall (ARM vs PA) - comparing builds - are we doing it right (koji-shadow vs mass queuing)?
3) Defining release criteria for F18
4) Raspberry Pi Remix Update
5) Your topic here
If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting.
On 08/07/2012 02:43 PM, Scott Sullivan wrote:
> On 08/07/2012 12:36 PM, Jon wrote:
>> On Tue, Aug 7, 2012 at 11:09 AM, Scott Sullivan <scott(a)ss.org> wrote:
>>> On 08/06/2012 11:59 PM, Jon wrote:
>>>> We might also consider making a wiki page for this device, ensure to
>>>> mention this is unsupported.
>>> Where do you want it?
>> How about here:
>> [does not exist yet]
> I've got the ball rolling with a very rough page. I will certainly need
> to do some more work on it later.
>> Presumably these steps will work with the mk802?
>> I'll attempt to reproduce your results soon, hopefully tonight.
> Yes, the hardware packs make it rather easy to get started and are being
> used with Debian, Ubuntu (normal and linaro) rootfs. The Uboot variables
> and kernel configs differ somewhat between device, but that is hidden in
> the hardware packs.
>> Have you seen this?
>>  https://www.miniand.com/forums/forums/2/topics/42
>> They have a Fedora image for mk802 (allwinner a10) with a UI.
>> An opportunity take a look at some prior art, though I don't see any
>> build steps.
> I knew about the device (have a friend with one) but I hadn't yet seen
> Fedora on it.
>> Hopefully we can document the build steps for others to follow on the
> With you there.
Forgot to push to list.
Regarding your query on #fedora-arm last week...
I have been working on installer options for ARM, and have been testing
some of this on a couple of different platforms. I have posted
information regarding this on the Wiki:
Through this effort I have made a few observations.
1) We currently support two basic types of installations for ARM, image
creation (livemedia-creator) and kickstart installs (anaconda). Which
is used will depend on the specific platform, for example highbank would
typically use a kickstart install where omap and tegra would use an
image creation, although highbank may still use image creation.
NOTE: Both types require a kickstart file to drive the installation.
Neither currently supports interactive installations. This would
require full U-Boot support in anaconda for all supported platforms.
2) There is little in common in the U-Boot environment among the various
ARM platforms. The specific load commands, load addresses, etc. vary
widely, as does support for device-tree.
3) Adding U-Boot support into anaconda will require a lot of
platform-specific details, which adds to the maintenance issue as
platforms are added or details change.
4) Even if we have the above mentioned U-Boot support included in
anaconda, it will not address the differences between boards of a given
platform, i.e., for OMAP - BeagleBoard, BeagleBone, Panda, etc.
5) While we could include some default image for each platform, we can't
provide support for all variants that users may desire, for example,
Trim Slice can be installed on SDCard (mmc) or hard drive (usb), but we
can only provide one 'default' image for 'tegra' in anaconda.
5) Changes to U-Boot itself would also require corresponding changes in
anaconda, for example adding uEnv.txt or bootz support (again, a
Based on these observations, I'd like to suggest that we consider our
approach and look at alternatives that would 1) be readily accepted
upstream, 2) be supportable/maintainable, and 3) meet the installation
needs of the community. Just to summarize some possible approaches:
1) Include support for all ARM platforms in Anaconda (U-Boot classes)
2) Use the %post script in Kickstart to configure for U-Boot
3) Hybrid approach (some support in anaconda, and the remainder in
4) Use 'generic' platform images and a separate 'deployment tool' for
board specific images.
Each of these approaches has pros and cons, some mentioned above.
Currently we are using #2 (%post script in Kickstart). It works well
enough for some boards, and can be board-specific without any changes to
anaconda. The biggest issue so far is that it will not support the OMAP
boards, due to partition issues (first partition must be VFAT and
include MLO and U-Boot). I'm sure we would encounter similar issues on
some other boards (i.e., *plugs)
I would like us to consider two approaches...
#3 - Hybrid approach, add only "minimal" U-Boot support to anaconda
(i.e., set up a uboot partition for OMAP), but not populate the U-Boot
partition or set up the boot.scr. These 'board specific details' could
be kept in the kickstart file %post script. This would keep anaconda
"cleaner" (less platform-specific code) and remain flexible, by adding
or changing board-specific support in the kickstart scripts.
#4 - Deployment Tool would not require any U-Boot support in anaconda,
but instead would create a 'standard format' image (one that includes
the 'platform' bits, e.g. correct kernel, but not the board-specifics)
and would use a deployment tool like the one Jon Chiappetta did for the
Raspberry Pi to create the actual 'image' (board-specific partitions,
loader/u-boot, device tree, etc.) This would only be needed for boards
that use the livemedia-creator images. Perhaps the Raspberry Pi
deployment tool could be updated to handle other boards as well.
I understand that neither of these two approaches would support
interactive installations, but I don't see this as a huge issue at this
time, since most of the current platforms either would not support a
full anaconda install running natively anyway (resource constraints) or
will typically be installed via PXE-boot/kickstart in a server environment.
I think either of the last two approaches could work for us, and provide
a supportable yet flexible approach for creating images for ARM systems
which use U-Boot. Please share you thoughts on these, and possibly
other approaches that we should consider. Hopefully we can come to a
consensus on an approach to implement for F18.