[meta-xilinx] qemuzynq fails to boot

[Simon Vincent]

I am not sure why we have it set to mtdev! However it looks like bitbake 
ignores it.

With it set to mtdev bitbake compiles and it hangs on boot.
With it set to mdev I get a bitbake error. "ERROR: Nothing RPROVIDES 'mdev'"
With it blank (VIRTUAL-RUNTIME_dev_manager = "") it hangs on boot the 
same as mtdev.

On 24/09/14 10:25, Mike Looijmans wrote:
> should that be "mdev" instead of "mtdev"?
>
> On 09/24/2014 11:14 AM, Simon Vincent wrote:
>> I have just done a few more builds and can confirm that sysvinit does 
>> work
>> with the default options.
>> The problem seems to be I was building sysvinit with mtdev.
>> VIRTUAL-RUNTIME_dev_manager = "mtdev"
>> sysvinit with udev works
>> sysvinit with mtdev fails
>>
>> Regards
>>
>> Simon
>>
>> On 24/09/14 08:16, Nathan Rossi wrote:
>>>>
>
> Met vriendelijke groet / kind regards,
>
> Mike Looijmans
>
> TOPIC Embedded Systems
> Eindhovenseweg 32-C, NL-5683 KH Best
> Postbus 440, NL-5680 AK Best
> Telefoon: (+31) (0) 499 33 69 79
> Telefax:  (+31) (0) 499 33 69 70
> E-mail: mike.looijmans at topic.nl
> Website: www.topic.nl
>
> Please consider the environment before printing this e-mail
>
> Topic zoekt gedreven (embedded) software specialisten!
> http://topic.nl/vacatures/topic-zoekt-software-engineers/
>
> -----Original Message-----
>>>> From: Simon Vincent [mailto:simon.vincent at xsilon.com]
>>>> Sent: Monday, September 22, 2014 6:09 PM
>>>> To: Nathan Rossi
>>>> Cc: meta-xilinx at yoctoproject.org
>>>> Subject: Re: [meta-xilinx] qemuzynq fails to boot
>>>>
>>>> I managed to get it working in the end by tweaking my local.conf.
>>>> I posted the solution on the xilinx forum.
>>>> http://forums.xilinx.com/t5/Embedded-Linux/Qemu-fails-to-boot-zynq-
>>>> image/m-p/518373/highlight/false#M10515
>>>> The solution is to use systemd instead of sysvinit.
>>>>
>>>> Systemd is not ideal for embedded targets so it would be good if I can
>>>> switch back to sysvinit.
>>> The default nodistro oe-core should work fine, and sysvinit should 
>>> work fine
>>> to. Which is what I am seeing with my builds.
>>>
>>> I noticed a very curious error message in your bootlog:
>>> Starting Bootlog daemon: bootlogd: cannot find console device 249:0 
>>> under /dev
>>>
>>> It looks like the serial device is missing, more interestingly it 
>>> looks like
>>> the image you have built is not running the udev during init. You 
>>> should
>>> have the following messages right after the kernel starts init:
>>>
>>> INIT: version 2.88 booting
>>> Starting udev
>>> [    4.522565] udevd[573]: starting version 182
>>>
>>> Would you be able to provide the rootfs image you built? This looks 
>>> like an
>>> odd bug.
>>>
>>> Regards,
>>> Nathan
>>>
>>>> Simon
>>>>
>>>> On 22/09/14 02:53, Nathan Rossi wrote:
>>>>>> -----Original Message-----
>>>>>> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
>>>>>> bounces at yoctoproject.org] On Behalf Of Simon Vincent
>>>>>> Sent: Thursday, September 11, 2014 12:40 AM
>>>>>> To: meta-xilinx at yoctoproject.org
>>>>>> Subject: [meta-xilinx] qemuzynq fails to boot
>>>>>>
>>>>>> I have built a linux image for qemu-zynq via setting my yocto 
>>>>>> machine
>>>> to
>>>>>> qemuzynq and doing a bitbake core-image-minimal
>>>>>>
>>>>>> I then try and run the image on qemu via the following command:
>>>>>> runqemu qemuzynq nographic
>>>>>>
>>>>>> I then find it starts to boot and locks up at the end. I get the
>>>>>> following error messages:
>>>>>> Stopping Bootlog daemon: bootlogd.
>>>>>> INIT: Id "PS0" respawning too fast: disabled for 5 minutes
>>>>>> INIT: Id "1" respawning too fast: disabled for 5 minutes
>>>>>> INIT: no more processes left in this runlevel
>>>>>>
>>>>>> The full boot output can be found at:
>>>>>> http://pastebin.com/MvEHN9Tk
>>>>> Hi,
>>>>>
>>>>> I have been away for a few weeks, so I have only just had a chance to
>>>> look at this. Is this still an issue? As I am unable to reproduce this
>>>> with meta-xilinx + oe-core master.
>>>>> If it is, could you provide your build setup (the message at the 
>>>>> top of
>>>> a bitbake run is sufficient).
>>>>> Regards,
>>>>> Nathan
>>
>