Fedora ARM weekly status meeting 2012-09-26
by Paul Whalen
Good day all,
This weeks Fedora ARM status meeting will take place today (Wednesday Sept 26th) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm
Current items on the agenda:
1) F18/19 Build status - problem packages
2) 3.6 kernel mmc driver - status update
3) VFAD summary
4) Raspberry Pi status 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.
Paul
11 years, 7 months
Fedora ARM weekly status meeting 2012-08-15
by Paul Whalen
Good day all,
This weeks Fedora ARM status meeting will take place today (Wednesday Aug 15th) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm
Current items on the agenda:
1) Build status update - packages needing attention
2) missing mock configs for F18
3) Raspberry Pi status update
4) Linaro Connect - single kernel binary status 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.
Paul
11 years, 8 months
Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?
by Steven A. Falco
On 08/07/2012 12:09 PM, Scott Sullivan wrote:
> On 08/06/2012 11:59 PM, Jon wrote:
>> On Mon, Aug 6, 2012 at 8:52 PM, Steven A. Falco <safalco(a)optonline.net> wrote:
>>> On 08/03/2012 06:12 AM, Peter Robinson wrote:
> [...]
>>>
>>> Ok - I have Fedora 17 running on the Mele. It is quite a hack, but it
>>> is usable (yum merrily installing the dev tools as we speak).
>>>
>>> Here is the recipe:
>>>
>>> 1) grab and cross-compile a copy of the kernel from:
>>> git://github.com/amery/linux-allwinner.git
>>> (use branch allwinner-v3.0-android-v2 with sun4i_defconfig)
>>> 2) grab http://hands.com/~lkcl/mele-ubuntu-lucid.img.lzma and write it
>>> to an SD card (don't forget to decompress it). Afterwards, use
>>> gparted to expand the ext partition to fill the SD card.
>>>
>>> 3) Mount the various partitions of the SD card on a host machine. On
>>> the fat partition, replace uImage with the one you just built. On
>>> the ext partition, blow everything away, and replace with an untar of:
>>>
>>> http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images...
>>>
>>> 4) Install the modules that go with the kernel you built to the ext
>>> partition (into /lib/modules/3.0.38+).
>>>
>>> 5) Stick the SD card in the Mele, and it should boot.
>
> Alternatively and Cleaner:
>
> 1) Download A1000 hardware pack from nightly builds. This is a Kernel and Uboot pre-built.
>
> http://rhombus-tech.net/allwinner_a10/nightly_build_images/
>
> 2) Grab the a1x-media-create.sh Script.
>
> # Needs to be Modified to support Fedora .zx tar archive and /lib symbolic link. Working on a patch.
Here is a patch that fixes both the xz and symbolic link:
--- /home/sfalco/a1x-media-create.sh 2012-08-08 14:10:38.323150167 -0400
+++ ./a1x-media-create.sh 2012-08-08 14:38:29.609848573 -0400
@@ -107,6 +107,8 @@
sudo tar xzf ../$1
elif [ ${fileext} == "7z" ] | [ ${fileext} == "lzma" ]; then
sudo 7z x ../$1
+ elif [ ${fileext} == "xz" ]; then
+ sudo tar xJf ../$1
else
echo "Unknown file extension: ${fileext}"
popd
@@ -217,6 +219,14 @@
cleanup
fi
echo "Copy hwpack rootfs files"
+ # Fedora uses a softlink for lib. Adjust, if needed.
+ if [ -L mntSDrootfs/lib ]; then
+ # Find where it points. For Fedora, we expect usr/lib.
+ DEST=`/bin/ls -l mntSDrootfs/lib | sed -e 's,.* ,,'`
+ if [ "$DEST" = "usr/lib" ]; then
+ mv hwpack/rootfs/lib hwpack/rootfs/usr
+ fi
+ fi
sudo cp -a hwpack/rootfs/* mntSDrootfs >> ${logfile}
if [ $? -ne 0 ]; then
echo "Failed to copy rootfs hwpack files to SD Card"
>
> 3) Download the Fedora Root FS.
>
> 4) Run media build script.
>
> 5) Stick SD card in the Mele and it will boot.
>
> This removes the dependence on the ubuntu image and automatically makes the partitions the correct size for the media.
>
>
>>> One big issue is that the built-in eth0 is not functional. That is true
>>> of the ubuntu build as well. To get around that, I plugged in a USB/ethernet
>>> adapter (and built the kernel module for it). That gave me a usable eth1.
>
> I got it to boot on Saturday using the method I outlined. I ran out of time to verify what did and didn't work.
>
>>> This clearly needs a ton of work to be a proper Fedora installation,
>>> but at least it is a start...
>
> Yes, certainly getting easier.
>
>> Sounds like a good start.
>>
>> We could probably just use the resize script in our image to expand
>> partition and resize ext on firstboot?
>
> No need with the creation script from the nightly builds. Otherwise we could re-purpose the scripts form the Raspberry Pi remix.
>
>> We might also consider making a wiki page for this device, ensure to
>> mention this is unsupported.
>
> Where do you want it?
>
11 years, 9 months
Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?
by Steven A. Falco
On 08/07/2012 12:09 PM, Scott Sullivan wrote:
> On 08/06/2012 11:59 PM, Jon wrote:
>> On Mon, Aug 6, 2012 at 8:52 PM, Steven A. Falco <safalco(a)optonline.net> wrote:
>>> On 08/03/2012 06:12 AM, Peter Robinson wrote:
> [...]
>>>
>>> Ok - I have Fedora 17 running on the Mele. It is quite a hack, but it
>>> is usable (yum merrily installing the dev tools as we speak).
>>>
>>> Here is the recipe:
>>>
>>> 1) grab and cross-compile a copy of the kernel from:
>>> git://github.com/amery/linux-allwinner.git
>>> (use branch allwinner-v3.0-android-v2 with sun4i_defconfig)
>>> 2) grab http://hands.com/~lkcl/mele-ubuntu-lucid.img.lzma and write it
>>> to an SD card (don't forget to decompress it). Afterwards, use
>>> gparted to expand the ext partition to fill the SD card.
>>>
>>> 3) Mount the various partitions of the SD card on a host machine. On
>>> the fat partition, replace uImage with the one you just built. On
>>> the ext partition, blow everything away, and replace with an untar of:
>>>
>>> http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images...
>>>
>>> 4) Install the modules that go with the kernel you built to the ext
>>> partition (into /lib/modules/3.0.38+).
>>>
>>> 5) Stick the SD card in the Mele, and it should boot.
>
> Alternatively and Cleaner:
>
> 1) Download A1000 hardware pack from nightly builds. This is a Kernel and Uboot pre-built.
>
> http://rhombus-tech.net/allwinner_a10/nightly_build_images/
>
> 2) Grab the a1x-media-create.sh Script.
>
> # Needs to be Modified to support Fedora .zx tar archive and /lib symbolic link. Working on a patch.
The following is all that is needed for the .xz stuff. I have
not looked at the /lib part.
--- /home/sfalco/a1x-media-create.sh 2012-08-08 14:10:38.323150167 -0400
+++ ./a1x-media-create.sh 2012-08-08 14:08:26.021655286 -0400
@@ -107,6 +107,8 @@
sudo tar xzf ../$1
elif [ ${fileext} == "7z" ] | [ ${fileext} == "lzma" ]; then
sudo 7z x ../$1
+ elif [ ${fileext} == "xz" ]; then
+ sudo tar xJf ../$1
else
echo "Unknown file extension: ${fileext}"
popd
>
> 3) Download the Fedora Root FS.
>
> 4) Run media build script.
>
> 5) Stick SD card in the Mele and it will boot.
>
> This removes the dependence on the ubuntu image and automatically makes the partitions the correct size for the media.
>
>
>>> One big issue is that the built-in eth0 is not functional. That is true
>>> of the ubuntu build as well. To get around that, I plugged in a USB/ethernet
>>> adapter (and built the kernel module for it). That gave me a usable eth1.
>
> I got it to boot on Saturday using the method I outlined. I ran out of time to verify what did and didn't work.
>
>>> This clearly needs a ton of work to be a proper Fedora installation,
>>> but at least it is a start...
>
> Yes, certainly getting easier.
>
>> Sounds like a good start.
>>
>> We could probably just use the resize script in our image to expand
>> partition and resize ext on firstboot?
>
> No need with the creation script from the nightly builds. Otherwise we could re-purpose the scripts form the Raspberry Pi remix.
>
>> We might also consider making a wiki page for this device, ensure to
>> mention this is unsupported.
>
> Where do you want it?
>
11 years, 9 months
Fedora ARM weekly status meeting 2012-08-08
by Paul Whalen
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):
PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm
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.
Paul
11 years, 9 months
Installer support for U-Boot
by d.marlin
Peter:
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:
http://fedoraproject.org/wiki/Architectures/ARM/Installer
http://fedoraproject.org/wiki/Architectures/ARM/Anaconda
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
maintenance issue).
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
kickstart)
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.
Thank you,
d.marlin
11 years, 9 months
Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?
by Jon
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:
>>
>> On Mon, Aug 6, 2012 at 8:52 PM, Steven A. Falco <safalco(a)optonline.net>
>> wrote:
>>>
>>> On 08/03/2012 06:12 AM, Peter Robinson wrote:
>
> [...]
>
>>>
>>> Ok - I have Fedora 17 running on the Mele. It is quite a hack, but it
>>> is usable (yum merrily installing the dev tools as we speak).
>>>
>>> Here is the recipe:
>>>
>>> 1) grab and cross-compile a copy of the kernel from:
>>> git://github.com/amery/linux-allwinner.git
>>> (use branch allwinner-v3.0-android-v2 with sun4i_defconfig)
>>> 2) grab http://hands.com/~lkcl/mele-ubuntu-lucid.img.lzma and write it
>>> to an SD card (don't forget to decompress it). Afterwards, use
>>> gparted to expand the ext partition to fill the SD card.
>>>
>>> 3) Mount the various partitions of the SD card on a host machine. On
>>> the fat partition, replace uImage with the one you just built. On
>>> the ext partition, blow everything away, and replace with an untar
>>> of:
>>>
>>>
>>> http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images...
>>>
>>> 4) Install the modules that go with the kernel you built to the ext
>>> partition (into /lib/modules/3.0.38+).
>>>
>>> 5) Stick the SD card in the Mele, and it should boot.
>
>
> Alternatively and Cleaner:
>
> 1) Download A1000 hardware pack from nightly builds. This is a Kernel and
> Uboot pre-built.
>
> http://rhombus-tech.net/allwinner_a10/nightly_build_images/
>
> 2) Grab the a1x-media-create.sh Script.
>
> # Needs to be Modified to support Fedora .zx tar archive and /lib symbolic
> link. Working on a patch.
>
> 3) Download the Fedora Root FS.
>
> 4) Run media build script.
>
> 5) Stick SD card in the Mele and it will boot.
>
> This removes the dependence on the ubuntu image and automatically makes the
> partitions the correct size for the media.
>
>
>
>>> One big issue is that the built-in eth0 is not functional. That is true
>>> of the ubuntu build as well. To get around that, I plugged in a
>>> USB/ethernet
>>> adapter (and built the kernel module for it). That gave me a usable
>>> eth1.
>
>
> I got it to boot on Saturday using the method I outlined. I ran out of time
> to verify what did and didn't work.
>
>
>>> This clearly needs a ton of work to be a proper Fedora installation,
>>> but at least it is a start...
>
>
> Yes, certainly getting easier.
>
>
>> Sounds like a good start.
>>
>> We could probably just use the resize script in our image to expand
>> partition and resize ext on firstboot?
>
>
> No need with the creation script from the nightly builds. Otherwise we could
> re-purpose the scripts form the Raspberry Pi remix.
>
That is the script I'm talking about, I believe it is on the Fedora
image you have used.
Look at your systemd units, it should just work on first boot.
>
>> 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:
http://fedoraproject.org/wiki/Architectures/ARM/AllwinerA10
[does not exist yet]
Presumably these steps will work with the mk802?
I'll attempt to reproduce your results soon, hopefully tonight.
Have you seen this?
[1] 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.
Hopefully we can document the build steps for others to follow on the wiki.
Thanks,
-Jon
11 years, 9 months
Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?
by Scott Sullivan
On 08/06/2012 11:59 PM, Jon wrote:
> On Mon, Aug 6, 2012 at 8:52 PM, Steven A. Falco <safalco(a)optonline.net> wrote:
>> On 08/03/2012 06:12 AM, Peter Robinson wrote:
[...]
>>
>> Ok - I have Fedora 17 running on the Mele. It is quite a hack, but it
>> is usable (yum merrily installing the dev tools as we speak).
>>
>> Here is the recipe:
>>
>> 1) grab and cross-compile a copy of the kernel from:
>> git://github.com/amery/linux-allwinner.git
>> (use branch allwinner-v3.0-android-v2 with sun4i_defconfig)
>> 2) grab http://hands.com/~lkcl/mele-ubuntu-lucid.img.lzma and write it
>> to an SD card (don't forget to decompress it). Afterwards, use
>> gparted to expand the ext partition to fill the SD card.
>>
>> 3) Mount the various partitions of the SD card on a host machine. On
>> the fat partition, replace uImage with the one you just built. On
>> the ext partition, blow everything away, and replace with an untar of:
>>
>> http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images...
>>
>> 4) Install the modules that go with the kernel you built to the ext
>> partition (into /lib/modules/3.0.38+).
>>
>> 5) Stick the SD card in the Mele, and it should boot.
Alternatively and Cleaner:
1) Download A1000 hardware pack from nightly builds. This is a Kernel
and Uboot pre-built.
http://rhombus-tech.net/allwinner_a10/nightly_build_images/
2) Grab the a1x-media-create.sh Script.
# Needs to be Modified to support Fedora .zx tar archive and /lib
symbolic link. Working on a patch.
3) Download the Fedora Root FS.
4) Run media build script.
5) Stick SD card in the Mele and it will boot.
This removes the dependence on the ubuntu image and automatically makes
the partitions the correct size for the media.
>> One big issue is that the built-in eth0 is not functional. That is true
>> of the ubuntu build as well. To get around that, I plugged in a USB/ethernet
>> adapter (and built the kernel module for it). That gave me a usable eth1.
I got it to boot on Saturday using the method I outlined. I ran out of
time to verify what did and didn't work.
>> This clearly needs a ton of work to be a proper Fedora installation,
>> but at least it is a start...
Yes, certainly getting easier.
> Sounds like a good start.
>
> We could probably just use the resize script in our image to expand
> partition and resize ext on firstboot?
No need with the creation script from the nightly builds. Otherwise we
could re-purpose the scripts form the Raspberry Pi remix.
> We might also consider making a wiki page for this device, ensure to
> mention this is unsupported.
Where do you want it?
--
Scott Sullivan
IRC: revident
11 years, 9 months
