I have installed Fedora 19 rootfs on my OMAP5432 uEVM board and booted
successfully with a patched upstream kernel. Everything looks fine except
the following message when booting:
Starting Terminate Plymouth Boot Screen...
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/usr/lib/python2.7/site-packages/initial_setup/__main__.py", line 5, in <module>
from pyanaconda.users import Users
File "/usr/lib/python2.7/site-packages/pyanaconda/__init__.py", line 36, in <module>
from pyanaconda.bootloader import get_bootloader
File "/usr/lib/python2.7/site-packages/pyanaconda/bootloader.py", line 32, in <module>
from blivet.devicelibs import mdraid
File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 68, in <module>
from devices import *
File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 105, in <module>
from devicelibs import dm
File "/usr/lib/python2.7/site-packages/blivet/devicelibs/dm.py", line 25, in <module>
File "/usr/lib/python2.7/site-packages/block/__init__.py", line 23, in <module>
from device import MultiPath, RaidDev, RaidSet, BlockDev, DeviceMaps, \
File "/usr/lib/python2.7/site-packages/block/device.py", line 259, in <module>
File "/usr/lib/python2.7/site-packages/block/device.py", line 264, in MPNameCache
for map in _dm.maps():
[ 17.228284] usb 1-3: link qh8-0001/edcd9b80 start 2 [1/0 us]
[ 17.235653] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 18.703451] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 18.712073] smsc95xx 1-3:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1
Although I don't think it is a big deal, is there anyone who could tell me
what problem it might be?
I am trying to track down a problem with the frama-c package. It runs
normally on i386 and x86_64, but exits immediately with an unhandled
exception on arm. It is written in ocaml, which makes debugging
difficult. I tried running it under valgrind to see if I could get any
clues, but valgrind says:
disInstr(arm): unhandled instruction: 0xEEBA5BEF
cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF)
==23036== valgrind: Unrecognised instruction at address 0x4f2d30.
==23036== at 0x4F2D30: caml_adjust_gc_speed (in
A gdb disassembly of the containing function shows that instruction as:
0x004f2d30 <+128>: vcvt.f64.s32 d5, d5, #1
Is that a legal instruction? I'm wondering if I should file a bug against
valgrind for not recognizing the instruction, or whether something in the
toolchain is emitting an instruction that is not valid for all CPUs in the
class Fedora supports.
Thank you for any help you can provide.
There is a HYP enabled u-boot floating around.
So far I've been unable to get it to boot Fedora, but others are welcome to try.
Here is the git for the above:
They also have some documentation:
On Wed, Aug 7, 2013 at 10:51 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> On Wed, Aug 7, 2013 at 4:47 PM, Adam Goode <adam(a)spicenitz.org> wrote:
>> Was there ever a resolution to this? I am happy to file a bug in the
>> chromium tracker to get this looked at, if needed.
> None that I'm aware of but if you could file a bug in the chromium
> tracker that would be fab.
>> On Fri, Jul 5, 2013 at 12:16 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
>>> On Fri, Jul 05, 2013 at 11:30:01AM -0400, Jon Masters wrote:
>>>> On 07/05/2013 05:07 AM, Richard W.M. Jones wrote:
>>>> > On Wed, Jul 03, 2013 at 11:59:28AM -0500, Jon wrote:
>>>> >> I'm pleased to announce the availability of Fedora 19 for the 2012 Samsung
>>>> >> Chromebook featuring ARM Exynos dual core A15 processor.
>>>> > Sorry to slightly hijack this thread. I will try your remix later.
>>>> > Reading the comments on https://lwn.net/Articles/557132/#Comments
>>>> > it seems as if the news on KVM on the Chromebook is not good. It
>>>> > doesn't boot into HYP mode, and there's no way to make it boot into
>>>> > HYP mode, so KVM won't be supported. Is that right?
>>>> That's roughly what I'd expect to be the case. There might be a signed
>>>> U-Boot someone has hacked that does enable HYP mode, but otherwise I
>>>> suspect you're out of luck. I'll ask around during Linaro Connect.
>>> I asked about this on #kvm-arm earlier today and got this long reply:
>>> 11:58 < rwmjones> I'm reading a comment here:
>>> 11:58 < rwmjones> https://lwn.net/Articles/557561/
>>> 11:58 < rwmjones> which suggests that KVM on the Samsung Chromebook 2012 (ARM A15 version) isn't possible because the
>>> bootloader doesn't boot into HYP mode
>>> 11:58 < rwmjones> is this true? if so is there a way around it?
>>> 11:59 < pm215> IIRC the bootloader gets control in secure-SVC
>>> 11:59 < pm215> it is from there possible to get to NS-HYP
>>> 11:59 < pm215> it's just that the stock bootloader doesn't do this before booting the kernel
>>> 11:59 < rwmjones> so what's involved in making it work?
>>> 11:59 < pm215> somebody needs to write some code and get it into the bootloader
>>> 12:00 < rwmjones> ok, and the bootloader can be replaced (next comment down suggests this requires soldering)?
>>> 12:01 < pm215> I believe this to be true, though I don't have a chromebook
>>> 12:01 < pm215> I think you get the google bootloader to chain boot some other bootloader which you do have control of, and then
>>> that can actually boot your os
>>> 12:02 < suihkulokki> or maybe we could just prepend some code in front of the kernel zimage that switches to HYP mode?
>>> 12:02 < pm215> nope
>>> 12:02 < suihkulokki> damn
>>> 12:02 < pm215> we spent quite a long time being very firm that the ABI here is "bootloader's job to get this right"
>>> 12:03 < pm215> there are some u-boot patches currently going through code review to do the go-to-hyp-mode thing properly for
>>> 12:03 < pm215> hopefully if they get upstream it will be more straightforward to say "ok, I have $other-board and it needs to
>>> do this too"
>>> 12:05 < apritzel> which would require that the Chromebook u-boot support is upstream as well
>>> 12:05 < apritzel> AFAIK this is not the case currently
>>> [There's more of this, but that seems to cover the main points]
>>> Reading around this, it does seem as if it's possible to get from
>>> secure SVC to HYP (although not easy).
>>> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>>> virt-top is 'top' for virtual machines. Tiny program with many
>>> powerful monitoring features, net stats, disk stats, logging, etc.
>>> arm mailing list
>> arm mailing list
> arm mailing list
I started working on moving some of the information from the ARM "Secret
Decoder Ring" page into the ARM Getting Started Guide. Right now I have
everything up to the section "Currently Supported ARM Architecture". I was
going to work down to the section title "What is U-Boot", but I am not sure
if that should all be in Introduction.xml or not.
Jared or Pete, do either of you have a working outline for this yet? I
would like to see this document ready for F20.
(I am including the ARM list of this to solicit feedback as well)