Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson
Hi all,
I would like to introduce myself to the group. I have recently
received an IGEPv2 board [1], which is based on the Beagle Board, but
with wifi, bluetooth, ethernet, and more RAM. I'm still at the "wow,
it's tiny and it runs Linux" stage. I should get a bit more time over
the next month and Christmas to play around properly with it.
I'm new to embedded development, but neither new to Linux nor ARM
(writing my first ARM assembly some 15 years ago). However, for the
past 6 years I've not even built a Linux kernel, preferring to use the
default kernel in Fedora for simplicity :)
Firstly, a thank you to those involved in Fedora ARM for getting it to
this stage. If I get the time, I'd really like to contribute some
(probably small) effort to help get Fedora ARM working well on the
IGEPv2 and Beagle Board. As I progress, I'd like to know what I can
do to help.
In the meantime, I have some questions. Apologies in advance if these
seem simple.
1) There are various different kernels from different sources. I'm
used to there being a small set of "right" kernels (that is, Fedora's
idea of "right") for x86. I fully appreciate that different ARM-based
boards are quite different in capabilities (like different instruction
set variants).
a) Is there likely to be some standardised vanilla Fedora ARM kernel
source? (Or is that simply the source RPM available for Fedora?)
Then patches /could/ be offered for the more common systems (e.g.
Beagle Board & clones, SheevaPlug).
b) Would it then make sense to offer these as pre-built RPMs for common systems?
c) Is there any guidance on which version is good to use as a base?
I've seen quite different kernel versions being used (from 2.6.27 to
2.6.31).
2) I understand a little bit about the different calling conventions,
FP differences (e.g. soft FPU versus VFP), and instruction set
differences (v5 versus v7).
a) Can the kernel can be safely built with a different instruction set
targeted? (I know there are different optimisation options passed to
GCC. Apologies if this seems a bit newbie-ish.)
b) For FP-heavy programs (e.g. ogg encoding), is it possible to build
the packages with VFP/NEON but still get them to work in a soft FPU
system? I'd imagine any call to an external library would have to
somehow be defined to use a different calling standard.
3) There seem to be some missing dependencies in the packages in the
current Fedora ARM repository. For example, emacs is requiring
libotf, which doesn't seem to be there in the repository. And
likewise with the xorg-x11-font* packages needing ttmkdir. I'm
confused as to how the RPM could have been successfully built without
it. What am I missing?
4) I see there has been some discussion over unaligned data access.
(Oh, I remember that from the ARM2 days.) It seems as if the
Cortex-A8 cores allow unaligned data access when set up to do so [2].
Does this, in any way, help with the compatibility of packages
targetting Cortex-A8?
5) I've managed to get various source packages missing from the Fedora
ARM repositories to compile successfully (natively). I guess there is
a reason why there are not in the repos right now -- is that reason
down to time and priorities, or is there some blocking bugs with many
of these packages?
I look forward to being able to contribute something back into Fedora!
Kind regards,
Matthew
[1] http://www.igep-platform.com/index.php?option=com_content&view=article&id...
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beih...
7 years, 9 months
Announcing Fedora 19 ARM remix for Allwinner SOCs release 3
by Hans de Goede
Hi All,
I'm very happy to announce the third release (r3) of my Fedora 19 ARM
remix images for Allwinner A10, A10s, A13 and A20 based devices. This
release is based on the official Fedora 19 Final for ARM images,
with u-boot and kernel(s) from the linux-sunxi project:
http://linux-sunxi.org/
New this release:
1) Fix the bad brown paper bag bug in r2 which caused it to not boot
on sun4i (A10) and sun5i (A13/A10s) devices
2) Support for the cubietruck (except for the wifi module)
3) Support for the Megafeis A08 and Mini-X with A10s
You can download it here:
http://people.fedoraproject.org/~jwrdegoede/a10-images/Fedora-19-a10-armh...
sha1sum: a57e5897e0c6047dbb473c438016d6364fd0709f
It is important to read the README, the image standard comes without
u-boot pre-loaded since u-boot is board specific. The image includes
a user-friendly simple script to install the right u-boot for
your board, but if you simply xzcat the image to an sdcard, and then
boot your device with the sdcard, things will *not* work.
See the README for a list of currently supported boards.
Known Issues:
-Many boards don't have an rtc (A10 and A20 have a builtin one),
or at least no battery backup for it, resulting in the date
+ time being wrong.
-If the date is of by more then a couple of months, "yum update"
won't work because certificate validation fails for the https
connection yum tries to make. So if yum fails to get its repodata
first check (and fix) your date
-The regular (host not otg) usb-port on A10s based boards can be a
bit quirky. It is best to plug in a hub even when using only one
device, otherwise the device may not be recognized. If this happens,
after adding a hub, often a power-cycle is needed too.
-The wifi chip on the Auxtek-T004 hdmi-stick and on the cubietruck are
unsupported atm
Enjoy,
Hans
And to make sure everyone reads the README, let me print it here
in full:
Fedora 19 ARM for Allwinner A10, A10s, A13 and A20 devices README
-----------------------------------------------------------------
Quickstart guide
----------------
1) Insert an sdcard, note any data on the card will be destroyed!
2) Make sure the card is not mounted, run "mount" and if the card shows
up in the output umount its partitions
3) Write the img file to the card, ie as root do:
xzcat Fedora-19-a10-armhfp-r2.img.xz > /dev/mmcblk0
sync
4) The card is not yet ready for use! Since the A10 u-boot is board
specific, the image comes without any uboot install, follow the next
steps to install the right u-boot for your board
5) Remove the card, and re-insert it. The uboot partition should get
automatically mounted, if not mount it manually,
6) As root (or through sudo) run: <uboot-part-mount>/select-board.sh, ie:
sudo /run/media/hans/uboot/select-board.sh
If you've dialog installed the select-board.sh script will prompt for
your board. If you don't have dialog installed, it will print the list
of supported boards. Lookup your board and re-run the script with the
shortname for your board as argument, ie:
sudo sh /run/media/hans/uboot/select-board.sh mk802
7) umount the uboot and rootfs partitions, ie:
umount /run/media/hans/uboot
umount /run/media/hans/rootfs
8) Your sdcard is now ready for use
9) *Before* powering up your A10 device connect it to an hdmi or dvi monitor
10) When first booting from the sdcard inserted Fedora will automatically
reboot once, this is part of the process to resize the root partition to
fill the entire sdcard and is normal behavior.
11) After the automatic reboot Fedora will start with the initial-setup wizard:
11a) Configure networking, note:
* If you've an A10 board with wired ethernet and you want to use dhcp
you don't need to do anything.
* If you've an A20 board, your ethernet may have a random mac-address,
so if you want to configure a static ip-address and want it to stick
across reboots, go to the ethernet-tab, select the mac-address field
and delete its contents, so that the static ip address you're
configuring does not get tied to the random mac-address.
11b) Setup the time zone
11c) Set a root password
11d) Create a user
12) Log in as the just created user
13) Enjoy Fedora on your A10 device
Supported Devices:
------------------
Fedora 19 ARM for Allwinner A10 has been tested with the following devices:
* A10s-OLinuXino-MICRO (Olimex)
* A13-OLinuXino (Olimex)
* A13-OLinuXino-MICRO (Olimex)
* A20-OLinuXino-MICRO (Olimex)
* Auxtek T003 hdmi tv stick
* Auxtek T004 hdmi tv stick
* BA10 TV Box
* Cubieboard development board 1024 MB RAM
* Cubieboard2 (A20) development board
* Cubietruck development board
* Gooseberry development board
* Mele A1000G/A2000G 1024 MB RAM
* Mini-X 1024 MB RAM
* mk802 (with female mini hdmi) 512 MB RAM
* mk802 with A10s (s with a circle around it on the barcode label)
* mk802ii (with male normal hdmi) 1024 MB RAM
* r7 hdmi tv stick
* UHost U1A hdmi tv stick
* Wobo i5 TV Box
Fedora 19 ARM should also work on the following devices:
* A10 tablet sold under various names (whitelabel)
* A13 tablet sold under various names (whitelabel)
* Coby MID7042 tablet
* Coby MID8042 tablet
* Coby MID9742 tablet
* Cubieboard development board 512 MB RAM
* DNS AirTab M82 tablet
* EOMA68 A10 CPU card
* H6 netbook
* Hackberry development board
* Hyundai a7hd tablet
* iNet-97F Rev.2 (and clones) tablet
* Marsboard A10
* Megafeis A08
* Mele A1000/A2000 512 MB RAM
* Mele A3700
* Mini-X 512 MB RAM
* Mini-X with A10s soc
* mk802 (with female mini hdmi) 1024 MB RAM
* pcDuino development board
* Point of View ProTab 2 IPS 9" tablet
* Point of View ProTab 2 IPS tablet with 3g
* Sanei N90
* XZPAD700 7" tablet
Configuring the display output
------------------------------
Multiple video outputs at the same time are not supported. By default
hdmi output with EDID is used for all devices, except for tablets/netbooks
where the default output is the lcd.
The default hdmi output with EDID will get the native resolution of your
TV / monitor and use that. Note that in order for this to work your TV /
monitor must be connected *and turned on*, before booting your device.
The output resolution can be configured with the disp.screen0_output_mode
kernel cmdline value, which can be found in the extrargs part of uEnv.txt in
the uboot partition. The default uEnv.txt contains the following value:
disp.screen0_output_mode=EDID:1280x720p60
This means try to use EDID and if no valid EDID info is found fallback to
1280x720p60.
The used output can be changed by adding disp.screen0_output_type=X to the
extraargs in uEnv.txt. With X being one of: 0:none; 1:lcd; 2:tv; 3:hdmi; 4:vga
Some per display type notes:
-lcd outputs: Hardcoded to the native mode, disp.screen0_output_mode is ignored
-tv: For the cvbs output disp.screen0_output_mode must be set to one of the
following: pal, pal-svideo, ntsc, ntsc-svideo, pal-m, pal-m-svideo, pal-nc,
pal-nc-svideo. Note the -svideo variants should only be used on boards with
an svideo connector, for composite out use the regular variants, ie:
disp.screen0_output_type=2 disp.screen0_output_mode=pal
-hdmi: To override the EDID detected mode, drop the "EDID:" from the
disp.screen0_output_mode value and set it to the desired mode, ie:
disp.screen0_output_type=3 disp.screen0_output_mode=1360x768p60
-vga: Does not support EDID, "EDID:" must be removed from the
disp.screen0_output_mode value otherwise it will be ignored. interlaced
progressive and refreshrate settings specified are ignored, each resolution
has hardcoded values for these. Example usage:
disp.screen0_output_type=4 disp.screen0_output_mode=1024x768
How to power your allwinner device
----------------------------------
For reliable operation it is important that your allwinner device is properly
powered. Some users try to power their allwinner development boards through
the power pin on the serial port / uart connector. This is a very bad idea!
and will almost always result in unreliable operation. Instaed always power
your allwinner device over the barrel connector intended for that using,
using a quality, reliable power supply.
USB controller caveats
----------------------
The OTG USB controller in host mode only supports a limited number of
devices, plugging in a hub + mouse + keyboard typically will make either
the mouse or keyboard not work. This is a hardware limitation which we
will likely not be able to work around.
On tv-sticks and top-set boxes, simply avoid the otg connector, instead
use a hub in a regular host usb connector. Note on the mini-x the otg / host
marking is not always correct. If things don't work try using the OTG
connector instead!
On tablets and the gooseberry unfortunately only the otg connector is
available. One solution there is using a single usb-device which is
both a keyboard and a mouse at the same time. IE the receiver for logitech
wireless desktop sets.
Known Issues
------------
* The broadcom sdio wifi found in the Auxtek T004 hdmi-stick and on the
Cubietruck is not supported
Supported hardware components / features:
-----------------------------------------
Fedora 19 ARM for Allwinner A10 supports the following components:
* CPU + PMU + RAM
* Serial ports
* MMC cards
* Internal NAND storage
* Framebuffer on lcd / vga / hdmi / composite video
* Sound both analog out and over hdmi
* OTG USB controller
* Both standard USB host controllers
* Wifi
* Wired Ethernet
* SATA
* IR (untested at this time)
* SPI (as module, not supported on A20)
* "tablet" keys on olinuxino boards
* 7 and 10 inch lcd displays on olinuxino boards (requires selecting the
right config in select-board.sh
Unsupported hardware components:
--------------------------------
The following components require various proprietary blobs to be used, and
as such are not supported in the Fedora images. The kernel drivers for them
are present (usually as modules), so if you add the necessary blobs you might
get these to work:
* Mali 400 GPU
* Cedar hardware video & audio decoding and encoding engine
* G2D 2d engine
Note that the drivers for these need some memory to be reserved at boot, and
since they are not supported by default in the Fedora images, this memory
reservation has been disabled. To reserve the memory edit /boot/uEnv.txt and
remove the kernel cmdline options which disable the memory reservation.
Differences from stock Fedora
-----------------------------
* Since the A10 is not a very powerful soc some services which are enabled by
default on Fedora are disabled in the image, see build-image.sh for a list.
* No plymouth: we log to a serial console for debugging so no pretty splash.
Also we don't use an initrd, so removing the console=ttyS0,115200 from
the extraargs in uEnv.txt will give plymouth, but so late it hardly matters.
Rebuilding the Fedora 19 ARM for Allwinner A10 disk image
---------------------------------------------------------
Building the Fedora 19 ARM for Allwinner A10 disk image consists of 2 steps
1) Building a uboot.tar.gz and rootfs.tar.gz "overlays", this is done
bu the build-boot-root-sh script
2) Combining uboot.tar.gz and rootfs.tar.gz with an official Fedora 19 arm img,
this combining is done by the build-image.sh script
The a10 image you downloaded is based on Fedora-XFCE-armhfp-19-1-sda.raw
These scripts are hosted here:
https://github.com/jwrdegoede/sunxi-fedora-scripts.git
A copy of the exact versions of these scripts used to build this Fedora A10
image can be found in the scripts directory of the uboot partition, the
kernel config used during the build can be found here too.
If you want to exactly reproduce this image it is important to use the
scripts from the scripts dir of the uboot partition, as the scripts contain
GIT tags used during the build to checkout the exact versions to build.
The pre-conditions these scripts expect to be met, and the exact usage of
them is documented in comments in the top of each script.
9 years, 1 month
Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
by Hans de Goede
Hi All,
I'm very happy to announce the first release (r1) of my Fedora 19 ARM
remix images for Allwinner A10, A10s, A13 and A20 based devices. This
release is based on the official Fedora 19 Final for ARM images,
with u-boot and kernel(s) from the linux-sunxi project:
http://linux-sunxi.org/
Besides all the goodies from Fedora-19, this release also contains
the following new items on the Allwinner / sunxi front:
-Support for the new dual core A20 soc (tested with cubieboard2),
this is based on forward porting the core machine code + various
drivers from allwinners 3.3 kernel source dump to the sunxi-3.4
sources. The following has been ported / is supported:
-uarts
-mmc controllers
-ehci and ohci usb controllers (usb controllers 1 and 2, controller
0 is an otg controller and is not supported yet.
-video output block (hdmi, vga, lcd, composite out)
-i2c controllers
-axp pmic including cpu voltage scaling
-rtc
-sound: analog in/out, hdmi audio, spdif out (spdif untested)
-ethernet controller (emac)
-sata controller
Note any functional blocks in the SOC which are not explictly
listed as supported above are not supported atm
-Support for a couple of new boards (38 boards in total now)
You can download it here:
http://scotland.proximity.on.ca/contrib-images/hansg/Fedora-19-a10-armhfp...
sha1sum: a179afafd77c26c7022392d2fa72e3fd221dd33a
It is important to read the README, the image standard comes without
u-boot pre-loaded since u-boot is board specific. The image includes
a user-friendly simple script to install the right u-boot for
your board, but if you simply xzcat the image to an sdcard, and then
boot your device with the sdcard, things will *not* work.
See the README for a list of currently supported boards.
Known Issues:
-Many boards don't have an rtc (A10 and A20 have a builtin one),
or at least no battery backup for it, resulting in the date
+ time being wrong.
-If the date is of by more then a couple of months, "yum update"
won't work because certificate validation fails for the https
connection yum tries to make. So if yum fails to get its repodata
first check (and fix) your date
-The regular (host not otg) usb-port on A10s based boards can be a
bit quirky. It is best to plug in a hub even when using only one
device, otherwise the device may not be recognized. If this happens,
after adding a hub, often a power-cycle is needed too.
-The wifi chip on the Auxtek-T004 hdmi-stick is unsupported atm
Enjoy,
Hans
And to make sure everyone reads the README, let me print it here
in full:
Fedora 19 ARM for Allwinner A10, A10s, A13 and A20 devices README
-----------------------------------------------------------------
Quickstart guide
----------------
1) Insert an sdcard, note any data on the card will be destroyed!
2) Make sure the card is not mounted, run "mount" and if the card shows
up in the output umount its partitions
3) Write the img file to the card, ie as root do:
xzcat Fedora-19-a10-armhfp-r1.img.xz > /dev/mmcblk0
sync
4) The card is not yet ready for use! Since the A10 u-boot is board
specific, the image comes without any uboot install, follow the next
steps to install the right u-boot for your board
5) Remove the card, and re-insert it. The uboot partition should get
automatically mounted, if not mount it manually,
6) As root (or through sudo) run: <uboot-part-mount>/select-board.sh, ie:
sudo /run/media/hans/uboot/select-board.sh
If you've dialog installed the select-board.sh script will prompt for
your board. If you don't have dialog installed, it will print the list
of supported boards. Lookup your board and re-run the script with the
shortname for your board as argument, ie:
sudo /run/media/hans/uboot/select-board.sh mk802
7) umount the uboot and rootfs partitions, ie:
umount /run/media/hans/uboot
umount /run/media/hans/rootfs
8) Your sdcard is now ready for use
9) *Before* powering up your A10 device connect it to an hdmi or dvi monitor
10) When first booting from the sdcard inserted Fedora will automatically
reboot once, this is part of the process to resize the root partition to
fill the entire sdcard and is normal behavior.
11) After the automatic reboot Fedora will start with the initial-setup wizard:
11a) Configure networking, note:
* If you've an A10 board with wired ethernet and you want to use dhcp
you don't need to do anything.
* If you've an A20 board, your ethernet will have a random mac-address,
so if you want to configure a static ip-address and want it to stick
across reboots, go to the ethernet-tab, select the mac-address field
and delete its contents, so that the static ip address you're
configuring does not get tied to the random mac-address.
11b) Setup the time zone
11c) Set a root password
11d) Create a user
12) Log in as the just created user
13) Enjoy Fedora on your A10 device
Supported Devices:
------------------
Fedora 19 ARM for Allwinner A10 has been tested with the following devices:
* A13-OLinuXino-MICRO (Olimex)
* Auxtek T003 hdmi tv stick
* Auxtek T004 hdmi tv stick
* BA10 TV Box
* Cubieboard development board 1024 MB RAM
* Cubieboard2 (A20) development board
* Gooseberry development board
* Mele A1000G/A2000G 1024 MB RAM
* Mini-X 1024 MB RAM
* mk802 (with female mini hdmi) 512 MB RAM
* mk802 with A10s (s with a circle around it on the barcode label)
* mk802ii (with male normal hdmi) 1024 MB RAM
* r7 hdmi tv stick
* UHost U1A hdmi tv stick
* Wobo i5 TV Box
Fedora 19 ARM should also work on the following devices:
* A10 tablet sold under various names (whitelabel)
* A13 tablet sold under various names (whitelabel)
* A10s-OLinuXino-MICRO (Olimex)
* A13-OLinuXino (Olimex)
* A20-OLinuXino-MICRO (Olimex)
* Coby MID7042 tablet
* Coby MID8042 tablet
* Coby MID9742 tablet
* Cubieboard development board 512 MB RAM
* DNS AirTab M82 tablet
* EOMA68 A10 CPU card
* H6 netbook
* Hackberry development board
* Hyundai a7hd tablet
* iNet-97F Rev.2 (and clones) tablet
* Mele A1000/A2000 512 MB RAM
* Mele A3700
* Mini-X 512 MB RAM
* mk802 (with female mini hdmi) 1024 MB RAM
* pcDuino development board
* Point of View ProTab 2 IPS 9" tablet
* Point of View ProTab 2 IPS tablet with 3g
* XZPAD700 7" tablet
Configuring the display output
------------------------------
Multiple video outputs at the same time are not supported. By default
hdmi output with EDID is used for all devices, except for tablets/netbooks
where the default output is the lcd.
The default hdmi output with EDID will get the native resolution of your
TV / monitor and use that. Note that in order for this to work your TV /
monitor must be connected *and turned on*, before booting your device.
The output resolution can be configured with the disp.screen0_output_mode
kernel cmdline value, which can be found in the extrargs part of uEnv.txt in
the uboot partition. The default uEnv.txt contains the following value:
disp.screen0_output_mode=EDID:1280x720p60
This means try to use EDID and if no valid EDID info is found fallback to
1280x720p60.
The used output can be changed by adding disp.screen0_output_type=X to the
extraargs in uEnv.txt. With X being one of: 0:none; 1:lcd; 2:tv; 3:hdmi; 4:vga
Some per display type notes:
-lcd outputs: Hardcoded to the native mode, disp.screen0_output_mode is ignored
-tv: For the cvbs output disp.screen0_output_mode must be set to one of the
following: pal, pal-svideo, ntsc, ntsc-svideo, pal-m, pal-m-svideo, pal-nc,
pal-nc-svideo. Note the -svideo variants should only be used on boards with
an svideo connector, for composite out use the regular variants, ie:
disp.screen0_output_type=2 disp.screen0_output_mode=pal
-hdmi: To override the EDID detected mode, drop the "EDID:" from the
disp.screen0_output_mode value and set it to the desired mode, ie:
disp.screen0_output_type=3 disp.screen0_output_mode=1360x768p60
-vga: Does not support EDID, "EDID:" must be removed from the
disp.screen0_output_mode value otherwise it will be ignored. interlaced
progressive and refreshrate settings specified are ignored, each resolution
has hardcoded values for these. Example usage:
disp.screen0_output_type=4 disp.screen0_output_mode=1024x768
USB controller caveats
----------------------
The OTG USB controller in host mode only supports a limited number of
devices, plugging in a hub + mouse + keyboard typically will make either
the mouse or keyboard not work. This is a hardware limitation which we
will likely not be able to work around.
On tv-sticks and top-set boxes, simply avoid the otg connector, instead
use a hub in a regular host usb connector. Note on the mini-x the otg / host
marking is not always correct. If things don't work try using the OTG
connector instead!
On tablets and the gooseberry unfortunately only the otg connector is
available. One solution there is using a single usb-device which is
both a keyboard and a mouse at the same time. IE the receiver for logitech
wireless desktop sets.
Supported hardware components / features:
-----------------------------------------
Fedora 19 ARM for Allwinner A10 supports the following components:
* CPU + PMU + RAM
* Serial ports
* MMC cards
* Internal NAND storage (*)
* Framebuffer on lcd / vga / hdmi / composite video
* Sound both analog out and over hdmi
* OTG USB controller (*)
* Both standard USB host controllers
* Wifi
* Wired Ethernet
* SATA
* IR (untested at this time) (*)
*) Not supported on A20, the A20 support in the Fedora 19 A10 images is new,
and as such the driver code for these has not been forward-ported from the
Allwinner source dump to the sunxi-3.4 kernel the Fedora 19 A10 images use yet.
Unsupported hardware components:
--------------------------------
The following components require various proprietary blobs to be used, and
as such are not supported in the Fedora images. The kernel drivers for them
are present (usually as modules) (*), so if you add the necessary blobs you
might get these to work:
* Mali 400 GPU
* Cedar hardware video & audio decoding and encoding engine
* G2D 2d engine
*) Except for the A20
Differences from stock Fedora
-----------------------------
* Since the A10 is not a very powerful soc some services which are enabled by
default on Fedora are disabled in the image, see build-image.sh for a list.
* No plymouth: we log to a serial console for debugging so no pretty splash.
Also we don't use an initrd, so removing the console=ttyS0,115200 from
the extraargs in uEnv.txt will give plymouth, but so late it hardly matters.
Rebuilding the Fedora 19 ARM for Allwinner A10 disk image
---------------------------------------------------------
Building the Fedora 19 ARM for Allwinner A10 disk image consists of 2 steps
1) Building a uboot.tar.gz and rootfs.tar.gz "overlays", this is done
bu the build-boot-root-sh script
2) Combining uboot.tar.gz and rootfs.tar.gz with an official Fedora 19 arm img,
this combining is done by the build-image.sh script
The a10 image you downloaded is based on Fedora-XFCE-armhfp-19-1-sda.raw
These scripts are hosted here:
https://github.com/jwrdegoede/sunxi-fedora-scripts.git
A copy of the exact versions of these scripts used to build this Fedora A10
image can be found in the scripts directory of the uboot partition, the
kernel config used during the build can be found here too.
If you want to exactly reproduce this image it is important to use the
scripts from the scripts dir of the uboot partition, as the scripts contain
GIT tags used during the build to checkout the exact versions to build.
The pre-conditions these scripts expect to be met, and the exact usage of
them is documented in comments in the top of each script.
9 years, 9 months
How to debug: Initramfs unpacking failed: junk in compressed archive
by Alex Villacís Lasso
I am working on this davinci-based ARMv5 board. This board runs Fedora 15 armv5tel with a kernel package I compiled myself for the board. The boot SD contains a FAT partition with the uImage kernel, and a ext4 filesystem that contains the root filesystem.
Up to now, I can run the kernel and boot the system without an initramfs by adding "root=/dev/mmcblk0p2 rw rootwait" to the kernel command line. So far, it works fine.
[root@elx ~]# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 227.32
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Hardware : DaVinci DA850/OMAP-L138/AM18x EVM
Revision : 0000
Serial : 0000000000000000
Now, I want to change the filesystem layout. I want to put all of /usr in a separate partition, and mount this read-only. For this, I want to boot the board using an initramfs. So, I ran the following command with the FAT partition mounted on /uboot:
[root@avillacis arm]# mkimage -A arm -T ramdisk -C none -a 0xc2000000 -n "mcuzone-initramfs-3.5.6-1.fc17" -d /run/media/alex/rootfs/boot/initramfs-3.5.6-1.elastixarm.fc17.armv5tel.mcuzone.img /run/media/alex/BOOT/initramfs-mcuzone.img
Image Name: mcuzone-initramfs-3.5.6-1.fc17
Created: Tue Oct 22 14:23:48 2013
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 7861729 Bytes = 7677.47 kB = 7.50 MB
Load Address: c2000000
Entry Point: c2000000
BTW, the kernel uImage is set to load at 0xc0008000. The board has system RAM from 0xc0000000 to 0xd0000000.
In the bootloader, after a few experiments, I found out that, while it will load the initramfs uImage, the bootlader will not add an ATAG describing the initramfs in any way. I checked:
[root@elx ~]# hexdump -C /proc/atags
00000000 05 00 00 00 01 00 41 54 00 00 00 00 00 00 00 00 |......AT........|
00000010 00 00 00 00 03 00 00 00 07 00 41 54 00 00 00 00 |..........AT....|
00000020 04 00 00 00 02 00 41 54 00 00 00 10 00 00 00 c0 |......AT........|
00000030 13 00 00 00 09 00 41 54 72 6f 6f 74 3d 2f 64 65 |......ATroot=/de|
00000040 76 2f 6d 6d 63 62 6c 6b 30 70 32 20 72 77 20 72 |v/mmcblk0p2 rw r|
00000050 6f 6f 74 77 61 69 74 20 69 70 3d 6f 66 66 20 69 |ootwait ip=off i|
00000060 6e 69 74 72 64 3d 30 78 63 30 38 30 30 30 30 30 |nitrd=0xc0800000|
00000070 2c 37 38 36 31 37 32 39 00 00 00 00 00 00 00 00 |,7861729........|
00000080 00 00 00 00 |....|
00000084
Therefore, I am forced to specify the initramfs location via a initrd= kernel parameter. However, I am getting this "junk in compressed archive" and the initramfs gets ignored. I am not sure why the initramfs becomes invalid. The bootloader loads the
uImage at 0xc1000000 and extracts the contents at 0xc2000000, 16 MiB higher, and way past the places where the kernel is extracted. Specifying the exact byte size instead of 8M makes no difference. I tried to use the keepinitrd boot parameter, but once I
get to a prompt, I do not find a place where I can inspect the initramfs as seen by the kernel. I ran "gzip -t" on the original initramfs, and it checks out fine. Could you give me suggestions on how to debug this?
U-Boot > setenv bootargs root=/dev/mmcblk0p2 rw rootwait ip=off initrd=0xc2000000,8M; mmc rescan 0; fatload mmc 0 0xc0700000 uImage; fatload mmc 0 0xc1000000 initramfs-mcuzone.img; bootm c0700000 c1000000;
reading uImage
3448120 bytes read
reading initramfs-mcuzone.img
7861793 bytes read
## Booting kernel from Legacy Image at c0700000 ...
Image Name: mcuzone-3.5.6-1.fc17
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3448056 Bytes = 3.3 MiB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at c1000000 ...
Image Name: mcuzone-initramfs-3.5.6-1.fc17
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 7861729 Bytes = 7.5 MiB
Load Address: c2000000
Entry Point: c2000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.5.6-1.elastixarm.fc17.armv5tel.mcuzone (palosanto(a)rpmbuild-arm.elastix.palosanto.com) (gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) ) #1 Fri Mar 29 07:20:14 ECT 2013
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: DaVinci DA850/OMAP-L138/AM18x EVM
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] BUG: mapping for 0xffff0000 at 0xfffe0000 out of vmalloc space
[ 0.000000] DaVinci da850/omap-l138/am18x variant 0x1
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rw rootwait ip=off initrd=0xc2000000,8M
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] allocated 524288 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] Memory: 256MB = 256MB total
[ 0.000000] Memory: 243340k/243340k available, 18804k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0622f68 (6252 kB)
[ 0.000000] .init : 0xc0623000 - 0xc066adbc ( 288 kB)
[ 0.000000] .data : 0xc066c000 - 0xc06c6a90 ( 363 kB)
[ 0.000000] .bss : 0xc06c6ab4 - 0xc079e6bc ( 864 kB)
[ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS:245
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] Console: colour dummy device 80x30
[ 0.000320] Calibrating delay loop... 227.32 BogoMIPS (lpj=1136640)
[ 0.080067] pid_max: default: 32768 minimum: 301
[ 0.080536] Security Framework initialized
[ 0.080666] SELinux: Initializing.
[ 0.081482] Mount-cache hash table entries: 512
[ 0.083324] Initializing cgroup subsys cpuacct
[ 0.083374] Initializing cgroup subsys memory
[ 0.083479] Initializing cgroup subsys devices
[ 0.083511] Initializing cgroup subsys freezer
[ 0.083534] Initializing cgroup subsys net_cls
[ 0.083553] Initializing cgroup subsys blkio
[ 0.083569] Initializing cgroup subsys perf_event
[ 0.083937] CPU: Testing write buffer coherency: ok
[ 0.084169] ftrace: allocating 18656 entries in 37 pages
[ 0.156178] Setting up static identity map for 0xc0469cc0 - 0xc0469d18
[ 0.164684] devtmpfs: initialized
[ 0.168005] DaVinci: 144 gpio irqs
[ 0.169473] atomic64 test passed
[ 0.170251] NET: Registered protocol family 16
[ 0.206674] da850_evm_usb_init: before cfgchip2=0x0001ef00
[ 0.206709] da850_evm_usb_init: after cfgchip2=0x0001af02
[ 0.223659] bio: create slab <bio-0> at 0
[ 0.226056] SCSI subsystem initialized
[ 0.227728] usbcore: registered new interface driver usbfs
[ 0.227984] usbcore: registered new interface driver hub
[ 0.228572] usbcore: registered new device driver usb
[ 0.233488] NetLabel: Initializing
[ 0.233532] NetLabel: domain hash size = 128
[ 0.233550] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.233703] NetLabel: unlabeled traffic allowed by default
[ 0.234102] Switching to clocksource timer0_1
[ 0.315460] NET: Registered protocol family 2
[ 0.316158] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.317484] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.317834] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.318060] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.318080] TCP: reno registered
[ 0.318117] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.318168] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.318977] NET: Registered protocol family 1
[ 0.319845] Unpacking initramfs...
[ 0.319937] Initramfs unpacking failed: junk in compressed archive
[ 0.354933] Freeing initrd memory: 8192K
[ 0.356001] EMAC: RMII PHY configured, MII PHY will not be functional
[ 0.358747] audit: initializing netlink socket (disabled)
[ 0.358942] type=2000 audit(0.330:1): initialized
9 years, 11 months
ARM linux-3.11.1-300.fc19.armv7hl incorrect handling uint16_t in probe_kernel_read() probe_kernel_write() functions
by William Cohen
Hello Everyone,
I was reviewing the systemtap testsuite results for ARM on Fedora 19 and I found that one of the tests (systemtap.base/deref.stp) failing on ARM for uint16_t reads and writes. The same tests work on x86_64. There appears to be ARM specific code in linux/arch/arm/include/asm/uaccess.h to read and write memory. I suspect that the 16-bit case for copies isn't being handled correctly.
The issue can be observed by
# yum install kernel-devel systemtap-testsuite -y
# debuginfo-install kernel-`uname -r` -y
$ uname -a
Linux dhcp129-3.rdu.redhat.com 3.11.1-300.fc19.armv7hl #1 SMP Thu Sep 19 16:31:05 EDT 2013 armv7l armv7l armv7l GNU/Linux
$ rpm -q systemtap
systemtap-2.3-1.fc19.armv7hl
$cd /usr/share/systemtap/testsuite
$sudo make installcheck RUNTESTFLAGS="--debug systemtap.base/deref.exp"
On ARM Fedora 19 The tests reports some failures:
=== systemtap Summary ===
# of expected passes 2
# of unexpected failures 1
Looking at the systemtap.log shows the tests starting up, but the 16-bit read/write operations failing:
PASS: ./systemtap.base/deref.stp startup
PASS: ./systemtap.base/deref.stp load generation
systemtap ending probe
systemtap test failure - kread u16
systemtap test failure - kread const u16
systemtap test failure - kwrite u16
On x86_64 the tests all passed:
=== systemtap Summary ===
# of expected passes 6
I modified the deref.stp script to see precisely what the arm machine was reasing and writing. It looked like it only got the lower 8-bits of the 16-bit quanity correct. The uper 8-bits are non-zero but it isn't clear where those values are coming from.
-Will
9 years, 11 months
u-boot update testing
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
I have proposed
https://admin.fedoraproject.org/updates/uboot-tools-2013.10-2.fc20 as a
blocker for beta I would appreciate as many people testing it as
possible and providing karma in bodhi, thanks.
The build fixes autobooting for wandboard in my testing. In my testing
it has not locked up once either using extlinux, I have not yet tested
on other platforms.
Thanks in advance
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSZGWzAAoJEH7ltONmPFDRNQgP/05WLMj7iTh7vw2nx9TwF7+R
T86Nq7nusFP1N6nFox0TJ1VTauV8Kspz+W+UHXunGPo/FnrA+7iLfS4MBGyozjvk
u1SoAcTtyBil3pLyzP4Vc5RQlk/k2GhcGd5Emiy/YE5PSa/Em0R2rqlboWWmdE/P
NUEx3wVtGN4fwGoa9T/X60gpZ8LEbothbTtC/S58VwKxhuz8FVaMJ4L36sOVPCmZ
dmlTrQi6i0D/fh9dxwxz15WQtnjqY6KfGXbRmGkq82UJYaUsGxCRwm9kyY3Pr5f/
lFJuTyXtSyb+ski65iLo/KhzxSQjftT+QnKKIhtPqkOz0bX1HMLSWcMVf4y2FeIN
qkZd3VQ/BDs4vejeSQc0ZOlVIhep3AXTHZPx+72XU+R2ChDaVdUDIWd2YCRmNLyF
jcp8/HCE/Noycdoc1gzBFzEfrI6ZnQKLlH7wJR/GA5lysQq+rUq8gZmJaoDi6w0Y
njxZ+y13jSwIc/X2TMM/0fz43bayYvrfLM+Y81r0bwnPaL5HqLraG/yS4WHKonP2
wQiybXzcpQz9SZOjyWnQOmVVSb2gWpWETE29NBQSWSnj5uLFf3fCbfEUpNeU3G6u
IWdCkDrf1koSCSaQX777wcMQSEnhgEZp0ZkEdwnkQaX5FiYEqb8n3QHtyHxe90ST
7kaSy31EqL/C5AD+ULVg
=qT+w
-----END PGP SIGNATURE-----
9 years, 11 months
Fwd: Does clock_gettime support CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM?
by Dan Horák
forwarding a message from our Ruby maintainer asking for help
looks like a kernel problem, please see also
https://bugs.ruby-lang.org/issues/9008#note-3
Dan
-------- Původní zpráva --------
Předmět: Does clock_gettime support CLOCK_REALTIME_ALARM and
CLOCK_BOOTTIME_ALARM?
Datum: Thu, 10 Oct 2013 13:48:01 +0200
Od: Vít Ondruch <vondruch(a)redhat.com>
Komu: arm(a)lists.fedoraproject.org
Hi,
I am trying to build Ruby 2.1 for F21 and I observe following test
errors:
3) Error:
TestProcess#test_clock_getres_constants:
Errno::E524: Unknown error 524 - clock_getres
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1752:in
`clock_getres' /builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1752:in
`block in
test_clock_getres_constants' /builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1749:in
`each' /builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1749:in
`test_clock_getres_constants'
4) Error:
TestProcess#test_clock_gettime_constants:
Errno::E524: Unknown error 524 - clock_gettime
/builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1676:in
`clock_gettime' /builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1676:in
`block in
test_clock_gettime_constants' /builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1673:in
`each' /builddir/build/BUILD/ruby-2.1.0-preview1/test/ruby/test_process.rb:1673:in
`test_clock_gettime_constants'
It looks like CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM are not
supported, but the error code is completely strange to me. According to
the documentation, it should return EINVAL.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html
|
| [EINVAL]
| The clock_id argument does not specify a known clock.
Any help is appreciated.
Thanks
Vít
P.S. This is my upstream report: http://bugs.ruby-lang.org/issues/9008
P.S.2 I am not subscribed to this list, please keep me in the CC.
9 years, 11 months
