ZyXEL NSA emulation

MrDini
MrDini Posts: 12  Freshman Member
Second Anniversary
edited June 2019 in Personal Cloud Storage
Hi,

Since I have an ffp repository for the NSA series it would be a lot easier for me not to compile always on the machine and not even inside a very uncomfortable cross-compiling environment, but a complete qemu system emulation. I have the uImage and initramfs extracted from the latest firmware however I couldn't boot it...

I tried to run:
</code><code>qemu-system-arm versatilepb -m 128M -kernel uImage -initrd initramfs -nographic
But it kept booting forever without any output. I assume it needs the kirkwood machine type which I cannot find in the supported machine list of qemu? Or what else I am missing?

Thanks


#NAS_Jun_2019

Accepted Solution

  • Mijzelf
    Mijzelf Posts: 2,790  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary
    Answer ✓
    That's strange... Shouldn't I have at least some output regardless? I've seen two options to redirect the serial output using qemu. One was defining the use of ttyAM0 and the other method was the stdio redirection done

    If the kernel can't open the 'other side' of the serial port, you won't see anything. If you use uboot, there is something called 'earlyprintk', which AFAIK means that uboot passes a function pointer which can be used to write to the serial port initialized by uboot, so that the kernel can log until it has opened it's own serial port. But that moves the problem to uboot. Although a uboot for an Arm platform supported by qemu should be able to boot a Kirkwood kernel.

    By building the kernel you can add some generic serial port drivers, in hope one will fit the qemu serial port, but I don't know if the 'Kirkwood core' will try to use them.

All Replies

  • Mijzelf
    Mijzelf Posts: 2,790  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary
    Indeed, that ain't gonna work. The NSA kernel is designed to have it's console on serial, and the Kirkwood serial port is probably the only serial port for which a driver is available. So you won't see anything unless this port is simulated. And there are some other problems. For instance the startscript /etc/init.d/rcS will reboot the box if it can't find the right flash partitions.

    If this is only about ffp, you can use any (emulated) Armv5+ system. Ffp will happily run on any kernel 2.6.14+, or something like that.

    If you want the userland, you can clone the filesystem and cleanup /etc/init.d/rcS a bit, and chroot that.
  • MrDini
    MrDini Posts: 12  Freshman Member
    Second Anniversary
    edited June 2019
    That's strange... Shouldn't I have at least some output regardless? I've seen two options to redirect the serial output using qemu. One was defining the use of ttyAM0 and the other method was the stdio redirection done by this flag: 
    -serial stdio<br>
    /etc/init.d/rcS will reboot the box if it can't find the right flash partitions.

    Correct and I already modified that within the initramfs.

    And yes, I am using a chroot environment at the moment, however having the actual kernel loaded would be extremely useful in some cases.

    Well, your statement sounds totally clear and sounds like an impossible no what do you think about the serial output tweaking? Stuff like the webserver or anything else won't actually show up? What if I load the whole thing using u-boot? I could get one uboot up with the virt machine emulation...

    Also, what if I rebuild the kernel using the GPL source but enable some additional features?


    Thanks a lot

  • Mijzelf
    Mijzelf Posts: 2,790  Guru Member
    250 Answers 2500 Comments Friend Collector Seventh Anniversary
    Answer ✓
    That's strange... Shouldn't I have at least some output regardless? I've seen two options to redirect the serial output using qemu. One was defining the use of ttyAM0 and the other method was the stdio redirection done

    If the kernel can't open the 'other side' of the serial port, you won't see anything. If you use uboot, there is something called 'earlyprintk', which AFAIK means that uboot passes a function pointer which can be used to write to the serial port initialized by uboot, so that the kernel can log until it has opened it's own serial port. But that moves the problem to uboot. Although a uboot for an Arm platform supported by qemu should be able to boot a Kirkwood kernel.

    By building the kernel you can add some generic serial port drivers, in hope one will fit the qemu serial port, but I don't know if the 'Kirkwood core' will try to use them.

  • MrDini
    MrDini Posts: 12  Freshman Member
    Second Anniversary
    Okay, sounds great! I already have a working uboot under qemu, just need to figure out how can I load the kernel from there so either initialize the virtualization with network support (then tftp load) or find a way to attach a device. But that's my task to figure out!

    Thanks Mijzelf!

Categories

Consumer Product Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）