Yocto Morty kernel for MIPSfpga

This topic contains 5 replies, has 2 voices, and was last updated by  Thomas 3 months, 4 weeks ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #55610

    Thomas
    Member

    I have some experience with using Yocto and targeting Microblaze and ARM processors so I figured I would try using the meta-img layer to see if I can get something going on the Nexys4 DDR (machine, xilfpga) for a course project. I’ve been at this a few days now and I’m not entirely sure where the disconnect is.

    I began using the SoC project’s 2014.2 Xilinx project and upgraded it to 2016.2. I then upgraded the MIPSfpga core to a more recent version of the HDL. My output bit file can can still boot the original kernel provided in that zip file (MIPSfpga SoC), so that all seems fine as a starting point.

    For the meta-img layer, I paired it up with poky (Morty) as seems to be indicated both by the branch of meta-img and the documentation. I compared the state of the 4.8 kernel (in Morty) with the patches that were required back on the 4.1 kernel used in the MIPSfpga SoC project. At this point it looks like the patches have been pulled in for the xilfpga machine, so I went with it.

    I set the MACHINE for xilfpga and ran bitbake (core-image-minimal). Given the present configuration of this layer, it will produce a separate cpio.gz file system and kernel (vmlinux). Booting the kernel produces panic that a working init was not found (not surprising, since the the defconfig CONFIG_INITRAMFS_SOURCE=”” with this default).

    To setup bundling the kernel with the filesystem as indicated in the SoC Part2 guide for buildroot, I tried modifying the machine definition to bundle the rootfs corresponding to mipsfpga-soc-initramfs:

    INITRAMFS_IMAGE = "mipsfpga-soc-initramfs"
    INITRAMFS_IMAGE_BUNDLE = "1"
    

    The mipsfpga-soc-initramfs image definition points back to core-image-minimal among other things:

    include recipes-core/images/core-image-minimal.bb
    IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
    PACKAGE_INSTALL = "${IMAGE_INSTALL}"
    

    The result of building that image (bitbake mipsfpga-soc-initramfs) is a vmlinux-initramfs-xilfpga.bin, which is the kernel and file system combined. When I try to boot that however, I get another kernel panic. This time the error is with /dev/console, stating that I need to make sure my rootfs is okay.

    Kernel panic – not syncing: /dev/console is missing or not a character device!
    Please ensure your rootfs is properly configured
    
    —[ end Kernel panic – not syncing: /dev/console is missing or not a character device!
    

    This is all just a summary of everything I’ve been digging into and comparing over the last few days as I’ve gone deeper into search results on how to debug this.

    Do either of these scenarios sound familiar to anyone? Any debugging steps that I’m leaving out or should look into?

    #55611

    Thomas
    Member

    I managed to get my combined kernel+image to boot by specifying a pre-populated /dev. This however threw multiple errors about the RTC not being valid (i.e., that /dev/misc/rtc was invalid, which makes sense because it’s not in the default static /dev).

    If anyone has insights on perhaps where I should look to correct this issue with dynamic vs. static (i.e., specifying USE_DEVFS = “0” vs. the default “1”), I would appreciate the insight.

    #55616

    ZubairLK
    Member

    Hi,

    Congratulations on getting so many things working.

    Could you try enabling the following options in the Kernel configuration.

    CONFIG_DEVTMPFS=y
    CONFIG_DEVTMPFS_MOUNT=y

    Ideally, these should be in the defconfig but I may have missed something accidentally in the Yocto configuration file or in the upstreamed defconfig on kernel.org. Probably because of booting with the additional kernel boot argument. “devtmpfs.mount=1”

    Regards,
    ZubairLK

    1 user thanked author for this post.
    #55617

    Thomas
    Member

    Interesting, I hadn’t thought of using those flags. What I ultimately ended up doing was modifying the behavior of the

    initramfs-framework

    recipe so that it would skip attempting to discover the alternate root file system (and then mount it) for the sake of booting straight into the already-running file system. This allowed me to get rid of the above flag for forcing a static device mapping in favor of having UDEV available nearer to the beginning. This should (hopefully) facilitate others in adding access to the SD card in some later work.

    You can see my progress over on GitHub:

    https://github.com/btgoodwin/meta-img/tree/wip-mip2.0-rootfs
    https://github.com/btgoodwin/meta-img-manifest

    In the next week or two as this course wraps up, I would like to submit a pull request for the first one and change the ownership of the other to the MIPS org. If you’re not familiar with it, the manifest uses Google’s repo utility to stand up a project build area in a rather turn-key manner. Right now, the manifest will not work properly since it will pull from the morty branch of my meta-img rather than my work in progress branch where I’m adding/experimenting with the 2.0 MIPSfpga core and my other changes for the xilfpga.

    My current status is that I have all of the MIPSfpga SoC/Part2 patches ported to the 4.8 kernel source, which I’ve designated as the preferred provider for the xilfpga machine. I also added in recipes for LibFDC and the simple GPIO utility/lab, and then referenced them in the INITRAMFS image definition I described in the previous posts. The output of the process is the combined kernel and root file system with everything pre-installed. You load the bit file and then load that binary via GDB and boot it.

    So far I get an error with I2C’s driver starting up that it could not locate the clock. Using the suggested command line option to ignore missing clocks did not resolve it. Modifying the device tree element for I2C to reference the 50 MHz clock did, however.

    Next up, the simple GPIO example app does not work properly. It throws a bus error:

    Data bus error, epc == 34406cf0, ra == 004009a0
    Welcome to UIO test prog
    Opening file /dev/uio0 
    Trying to mmap memory
    Writing 0xf at location 0x10C0_0004. 4 LEDs will light up. 
    Bus error
    

    This is interesting because I can use devmem2 to read and write to the GPIO, but trying to communicate with 0x10C0xxxx results in a similar bus error. I’ve double-checked the Address Editor in Vivado, the output device tree I’m using, etc. so I’m not sure where the disconnect is for this custom core.

    I had an error relating to bootlogd starting because it needed CONFIG_LEGACY_PTYS set in the kernel configuration. Enabling that resolved the bootlogd error at the cost of nearly doubling the boot up time.

    Additionally the ethernet kernel driver appears to load properly and set a MAC, however the follow-on network configuration fails:

    Configuring network interfaces… net eth0: of_phy_connect() failed
    ifconfig: SIOCSIFFLAGS: No such device
    

    I probably will not have time to address either of these in the next couple of weeks as the class ends, and I return the hardware. If either issue looks familiar and you have a suggestion for fixing them, I would be happy to attempt fixing them.

    Cheers 🙂

    Thomas

    #55624

    ZubairLK
    Member

    Just to double check.

    Do these devices (uio/gpio/i2c/ethernet) work OK with your 2016.2 RTL/bitstream and the older provided vmlinux file?

    Also, have you followed steps to rebuild vmlinux/buildroot? Or did you directly go for Yocto?

    Regards,
    ZubairLK

    #55625

    Thomas
    Member

    The GPIO and I2C do work. UIO causes a bus error (same occurs if trying to read via /dev/mem from that address). The Ethernet kind-of works. It seems to correctly read the DTS and load the driver, but ifconfig is unable to load. After a lot of searching, I found a post from someone else using a board powered by USB (as is my situation with the Nexys 4 DDR). For them, they got the same ifconfig error until they swapped to an external power supply (I don’t have one, so I’m unable to test it).

    I did not try to rebuild using (your?) buildroot instructions. I was using the base kernel as a proof of life for my bitstream, which of course doesn’t have the rest of the peripherals integrated. I’m unfortunately out of time to go back through each of those labs to see if the buildroot route and patching the 4.1 kernel would work.

    1 user thanked author for this post.
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic.