make omap2plus_defconfig uImage took around 1400 minutes. I now believe the people that mentioned that the performance of a virtual system (on x86_64) is not very spectacular.initscripts in Fedora 14 and below. Fedora 15 uses systemd and is likely not affected with the same. This kernel (well, actually from 2.6.36 an onwards) have a optimized serial-port implementation for OMAP-boards. This unfortunately does not use ttyS* for serial-ports, but ttyO*. Any application (including initscripts) expecting that serial-ports are starting with ttyS or other familiar identifiers, will need an update for the OMAP serial-port driver.initscripts with the patch that makes ttyO work as main console (giving console=ttyO2,115200n8 on the kernel command line). When all works fine, the boot process will be displayed on the serial-console and logging in works again.initramfs via u-boot does not seem to be very common, most sites advise to compile the initramfs into the kernel. I'd prefer to keep the standard Fedora way, and that means keeping kernel and initramfs seperate. It seems that u-boot needs a special kind of initramfs/initrd (possibly just a header added). This format can be created like the following:mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000 -n initramfs -d initramfs-2.6.38-rc3.img uinitramfs-2.6.38-rc3.imgbootcmd to load both kernle + initramfs and passing both addresses via bootmOMAP3 beagleboard.org # printenv
stdin=serial
stdout=serial
stderr=serial
serial=3a5c00020000000004013ef109010017
bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro
bootcmd=mmcinit ; fatload mmc 0:1 0x80000000 uimage-2.6.38-rc3.beagleboard_201102131201 ; fatload mmc 0:1 0x81600000 uinitramfs-2.6.38-rc3.img ; bootm 0x80000000 0x81600000
Environment size: 309/131068 bytesmake beagleboard_defconfig), sadly that default is not available in current kernels anymore. taking an old config and updating it a little, got me a recent kernel (2.6.38-rc3) that seems to work on the beagleboard. beagleboard_defconfig was renamed several times, currently it is available as omap2plus_defconfig. I probably need to build a new kernel now... Unfortunately it takes quite a while to build a new kernel on an emulated ARM board (I'm not into crosscompiling with a recent gcc version yet). The SD card I have is a little small, putting both the root filesystem and the kernel-sources on it seems difficult, an exercise I'll experiment with later.init seems to require the /proc fileystem mounted, if it is not mounted, init decides to reboot the system as there are some process-communication issues. Starting with an emergency shell (pass init=/bin/dash on the commandline) allows me to manually mount /proc (even if it claims to be mounted already).CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=yWith these options enabled, the standard /dev/ttyS2 does not seem to provide any output. Instead it seems to be required to use the OMAP-specific /dev/ttyO2 (that's an 'O' for Oscar, not a '0' as zero).saveenv) looks like this:OMAP3 beagleboard.org # printenv
stdin=serial
stdout=serial
stderr=serial
serial=3a5c00020000000004013ef109010017
bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootwait init=/bin/dash
bootcmd=mmcinit ; fatload mmc 0:1 0x80000000 uimage-2.6.38-rc3.beagleboard_201102131201 ; bootm 0x80000000
Environment size: 267/131068 bytesdash as directed by the init parameter can be done as follows:OMAP3 beagleboard.org # boot
## Booting kernel from Legacy Image at 80000000 ...
Image Name: Linux-2.6.38-rc3.beagleboard
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1751256 Bytes = 1.7 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.38-rc3.beagleboard (root@fedora-arm) (gcc version 4.4.2 20091019 (Red Hat 4.4.2-5) (GCC) ) #2 Sun Feb 13 22:26:07 EST 2011
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootwait init=/bin/dash
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126296k/126296k available, 4776k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
vmalloc : 0xc8800000 - 0xf8000000 ( 760 MB)
lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.init : 0xc0008000 - 0xc002b000 ( 140 kB)
.text : 0xc002b000 - 0xc033d000 (3144 kB)
.data : 0xc033e000 - 0xc0369480 ( 174 kB)
NR_IRQS:402
Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
Reprogramming SDRC clock to 332000000 Hz
GPMC revision 5.0
IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP clockevent source: GPTIMER12 at 32768 Hz
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
Console: colour dummy device 80x30
Calibrating delay loop... 471.61 BogoMIPS (lpj=1843200)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
print_constraints: dummy:
NET: Registered protocol family 16
omap_device: omap_gpio.0: new worst case activate latency 0: 30517
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
omap_mux_init: Add partition: #1: core, flags: 0
OMAP3 Beagle Rev: unknown 3
omap_device: omap_uart.0: new worst case activate latency 0: 30517
omap_device: omap_uart.0: new worst case deactivate latency 0: 30517
Found NAND on CS0
Registering NAND on CS0
Unable to get DVI reset GPIO
OMAP DMA hardware revision 4.0
bio: create slab at 0
SCSI subsystem initialized
omap_device: omap_i2c.1: new worst case activate latency 0: 30517
omap_i2c omap_i2c.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
print_constraints: VUSB1V5: 1500 mV normal standby
print_constraints: VUSB1V8: 1800 mV normal standby
print_constraints: VUSB3V1: 3100 mV normal standby
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
print_constraints: VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby
print_constraints: VDAC: 1800 mV normal standby
print_constraints: VDVI: 1800 mV normal standby
print_constraints: VSIM: 1800 <--> 3000 mV at 1800 mV normal standby
omap_i2c omap_i2c.3: bus 3 rev3.12 at 100 kHz
Switching to clocksource 32k_counter
Switched to NOHz mode on CPU #0
musb-hdrc: version 6.0, tusb-omap-dma, peripheral, debug=0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 246
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
console [ttyO2] enabled
brd: module loaded
loop: module loaded
twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
omap_device: omap_i2c.1: new worst case deactivate latency 0: 30517
i2c /dev entries driver
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
omap_voltage_late_init: Unable to create voltage debugfs main dir
vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
vdd_debugfs_init: Unable to create debugfs directory for vdd_core
Power Management for TI OMAP3.
regulator_init_complete: VDVI: incomplete constraints, leaving on
regulator_init_complete: VDAC: incomplete constraints, leaving on
twl_rtc twl_rtc: setting system clock to 2000-01-01 00:03:14 UTC (946684994)
Waiting for root device /dev/mmcblk0p2...
mmc0: new SD card at address 9ced
mmcblk0: mmc0:9ced SD02G 1.89 GiB
mmcblk0: p1 p2
EXT3-fs: barriers not enabled
kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 179:2.
Freeing init memory: 140K
/bin/dash: can't access tty; job control turned off
# # mount /proc
# mount /sys
# exec initUnfortunately it looks as if upstart or udev from Fedora 12 does not recognise the /dev/ttyO* as serial console. Of course I do not have the possibility (hte beagleboard has, just I do not) to connect a monitor over HDMI or S-video and serial-console is the only working output available. Yet another thing to look into some other day.
linux-2.6/arch/arm/include/asm/atomic.h:42: error: impossible constraint in 'asm'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
minicom over the USB-serial converter to receive the output from the serial console. After transferring the root-filesystem to the SD-card, it is possible to send a u-boot image to the BeagleBoard over the serial-connection. Inside u-boot the command loady starts a filetransfer over the ymodem protocol. minicom can send a file after pressing "CTRL+A s". And while doing so, abrt created this bug.Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Error: reading boot sector
Loading u-boot.bin from nand
U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)
I2C: ready
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
DRAM: 128 MB
NAND: 256 MiB
MUSB: using high speed
In: serial
Out: serial
Err: serial
Board revision Ax/Bx
Serial #3a5c00020000000004013ef109010017
OMAP3 beagleboard.org # mmcinit
OMAP3 beagleboard.org # fatload mmc 0:1 0x80000000 uimage-2.6.34_201102061623
OMAP3 beagleboard.org # setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait nohz=off
OMAP3 beagleboard.org # bootm 0x80000000
## Booting kernel from Legacy Image at 80000000 ...
Image Name: Linux-2.6.34beagleboard
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1678404 Bytes = 1.6 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34beagleboard (nixpanic@fedora12.builder.nixpanic.net) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33.fa1)) #3 Sun Feb 6 16:18:40 GMT 2011
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board
init seems to be of the opinion that booting is not successful and a reboot is needed. Adding the 'kernel parameter' --verbose that does not get handled by the kernel, but by init, the following messages were written:Waiting for root device /dev/mmcblk0p2...
mmc0: new SD card at address 9ced
mmcblk0: mmc0:9ced SD02G 1.89 GiB
mmcblk0: p1 p2
kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): recovery complete
EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:2.
Freeing init memory: 136K
init: Control request to emit fedora.serial-console-available event
init: Handling fedora.serial-console-available event
init: serial goal changed from stop to start
init: serial state changed from waiting to starting
init: Handling starting event
init: serial state changed from starting to pre-start
init: Active serial pre-start process (453)
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Event queue paused
init: Control request for status of rcS
init: Control request for status of rcS
Restarting system.
init=/bin/dash seems to work and one can do some diagnosis. However when doing an exec init --verbose a reboot get initiated again :-/usb0. Everything indicates that this is possible, as a test-kernel I tried to start, resulted in these messages on my laptop:usb 1-1: New USB device found, idVendor=0525, idProduct=a4a2
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: RNDIS/Ethernet Gadget
usb 1-1: Manufacturer: Linux 2.6.28-omap1 with musb_hdrc
cdc_ether 1-1:1.0: usb0: register 'cdc_ether' at usb-0000:00:1a.7-1, CDC Ethernet Device, 8a:18:75:d3:a6:10
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver cdc_subset
usb0: no IPv6 routers present
usb 1-1: USB disconnect, address 43
cdc_ether 1-1:1.0: usb0: unregister 'cdc_ether' usb-0000:00:1a.7-1, CDC Ethernet Device
But of course, this test-kernel is affected by same reboot-problem.libvirt and virt-manager for work, running an ARM-emulation this way is my preferred setup.qemu-system-arm gets wrong arguments and a script that functions as a (temporary) workaround should be used. This was a note for Fedora 13, I'm running Fedora 14. So, of course I tried to start my VM without the script first:qemu-system-arm: -device lsi,id=scsi0,bus=pci.0,addr=0x5: Bus 'pci.0' not found
bus=pci.0 gets replaced by bus=pci. Manually starting qemu-system-arm with some adjusted bus= parameters seems to start the VM.libvirt for PPC emulation.gdb and manually executing qemu-system-arm and comparing it with qemu-kvm, it seems that the virtual hardware is configured differently. Most noticible (for me) seems to be the name of the PCI-bus, on qemu-system-arm it is pci and on qemu-kvm it is pci.0. The function qbus_find_recursive() can be used to breakpoint and to check the names of the available busses (bus->name).bus=pci or bus=pci.0 should work with any qemu-* command. Unfortunately it is unclear to me how qemu-kvm constructs the virtual hardware, the qemu-system-* are more transparent. Depending on the machine that is being emulated the hardware is 'connected' when the machine is created. The virtual hardware is constructed by qemu-kvm/hw/*.c and depends on the type of machine that is created.qemu-kvm/hw/*.c there are some uses of pci_register_bus() where pci as name for the PCI-bus is passed. It seems easy to rename the PCI-busses to pci.0. This change will break any existing scripts/tools that pass bus=pci on the command line, so the solution is not the best. However, packages are temporary available in case someone wants to try this solution.versatileab does not have an ISA-bus, therefore -device isa-serial can not work. The Serial device in the Virtual Machine needs to be removed. An alternative would be a usb-serial, but at the moment, virt-manager does not offer this option (you can probably configure it with virsh edit or virsh define though).versatileab machine. It can obviously not cope with the 512MB of RAM I gave it. The result was shown by virt-managerlibvirtError: operation failed: could not query memory balloon allocation
and in my /var/log/libvirt/fedora.arm.logqemu: hardware error: pl011_read: Bad offset 101f1018
Giving the machine only 256MB RAM instead of 512MB RAM seems to make this issue go away too.
Adobe also has a pre-release version of a 64-bit plugin. Until this is supported via yum, you will need to do the following:
1. Download the .tar.gz version from Adobe here.
2. Use "gtar -xzvf" to extract libflashplayer.so and put it in either in /usr/lib64/mozilla/plugins/ or ~/.mozilla/plugins/.
3. Restart Firefox.