As DebConf has a bunch of Opsis boards, I thought you might be interested in our progress on getting Linux running on the FPGA SoC that powers the HDMI2USB firmware.
We do really need more Linux Kernel and QEMU hackers, so if you have any friends who could help with that, please do point them our way! Tim 'mithro' Ansell ---------- Forwarded message ---------- From: Tim Ansell <[email protected]> Date: 30 April 2017 at 14:38 Subject: Current status of Linux on LiteX (2017/04/30) - Booting to userspace in QEMU! To: [email protected] Cc: Joel Stanley <[email protected]>, Hasjim Williams < [email protected]> Hi everyone! Just thought I would send out a status update for Linux on LiteX. At the moment, we have Linux booting to userspace in the QEMU emulated environment using LiteX based peripherals and or1k architecture! Currently we are still using the inbuilt or1k timer which is not available on the LiteX hardware (see https://github.com/timvideos/ linux-litex/issues//11 ). Once a driver for the LiteX timer is working then hopefully things will "just work" on real hardware. To get your own Linux on LiteX in QEMU you need to; 1) Build QEMU from the "linux-hacks" branch of https://github.com/ timvideos/qemu-litex - Follow instructions in the README.md - You can use QEMU inside a HDMI2USB-litex-firmware repo or from qemu repo. - You should use PLATFORM=mimasv2 TARGET=base CPU=or1k 2) Build a minimal rootfs CPIO archive using buildroot for o1k. 3) Build Linux from master branch of https://github.com/timvideos/ linux-litex - You should be able to use the committed .config file. - You will need an or1k toolchain. I'm using the gcc-or1k-elf-newlib toolchain from our conda repo, but you should be able to use the one from buildroot. 4) Load Linux into QEMU via gdb - The general principle is to start qemu with "-S -s" and then use something like the following in gdb; target remote :1234 load vmlinux 0x40000000 add-symbol-file vmlinux 0x40000000 add-symbol-file vmlinux 0xc0000000 source vmlinux-gdb.py jump *0x40000100 On real hardware we should be able to load the kernel+cmdline+initrd from the spiflash, serial and tftp (where Ethernet is available) using the LiteX BIOS rather than needing to use gdb. In theory the following peripherals should already work; * UART * spiflash - Both reading using the memory mapped interface and writing using the SPI bitbanging interface. * i2c and 2400 EEPROMs - Using the I2C master bitbanging interface. * sdcard - Using MMC SPI mode over the SPI bitbanging interface (this is obviously *super* slow). The two big peripherals (that are well out of my league) which need someone to work on are; * Ethernet driver for LiteEth - https://github.com/ timvideos/linux-litex/issues/2 * Framebuffer driver for LiteVideo output - https://github.com/ timvideos/linux-litex/issues/8 A lot of our stuff is still under heavy development and still very hacky. We want to eventually get both the QEMU and Linux changes upstream. We will probably need to figure out the device tree generation before we can do a lot of that. Currently our QEMU is about 6 months old, so I have started rebasing onto upstream QEMU (I sent my first patches for or1k changes the other week). With the rebased work lm32 + bare metal firmware boots but I have not had a chance to try or1k or Linux on it again. Love help if anyone has spare time, even helping write up some decent instructions or recruiting other people would be super awesome! Tim 'mithro' Ansell Pretend Linux Kernel Hacker ;-)
_______________________________________________ Debconf-video mailing list [email protected] http://lists.debconf.org/mailman/listinfo/debconf-video
