[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Debconf-video] Plans around your Opsis boards + HDMI2USB for DebConf video sprints?

Hi everyone,

If I understand correctly, next week a bunch of you will be meeting up in Paris for a DebConf video sprint?  Sadly, I won't be able to attend in person but I'm very interested in trying to help support you remotely from Australia. Luckily Paris daytime is my evening, so I should be available!

Do you have a todo list / agenda / other task tracking for what you hope to achieve at the event? I assume that there are a bunch of things related to your Opsis boards that would make sense to be worked on?

A couple of things which I would really love to see done are;

 * Finish the VGA board changes. 
    - This is currently pending on RattusRattus changes around the ESD protection. 
    - Once this has been finished, I can get my PCB designer to finish the routing and we can look at getting them made!

 * Getting the HDMI2USB-mode-switch tool (https://github.com/timvideos/HDMI2USB-mode-switch) packaging for Debian (and getting upstream).
   - This tool will be the primary mechanism for people to manage their HDMI2USB compatible boards and do things like upgrade the firmware on them.
   - There are some custom udev rules included with the tool (https://github.com/timvideos/HDMI2USB-mode-switch/tree/master/udev) which probably need hitting with a stick to be acceptable (they current set things to permission 0666).
   - There are extra features that I would love to add but these are not Debian specific things (IE Checking the existing firmware version and then downloading newer firmware from the prebuilt repo).

 * Start using the HDMI2USB-controlproxy-daemon (https://github.com/timvideos/HDMI2USB-controlproxy-daemon) and packaging it for Debian.
   - This tool converts the serial interface into a TCP socket and works around problems with the crappy serial implementations. It does things like sending data slowly, allowing multiple connections, etc.
   - The idea would be able to use this to allow monitoring of the state of your HDMI2USB boards. Things like the error rate, resolution detected, firmware versions in usage.
   - This is also the connection point for some type of GUI which allows controlling the connections and setup (see https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/41)

For those who aren't following the HDMI2USB firmware development closely, the following information is probably important for deciding where you spend your time;

We are currently trying to upgrade the firmware onto the newest version of litex + misoc. Doing this will enable things like a significantly faster build time, Ethernet support and merging a bunch of the GSoC student's work. This means substantial changes to the current firmware (found in https://github.com/timvideos/HDMI2USB-misoc-firmware) which can't be easily ported forward are not a good idea. 

This mean that the "little white bar" issue (which gets worse the more inputs and outputs you enable) probably does *not* make sense for you guys to investigate. The new versions include a rewritten DRAM controller and the old DRAM controller is likely what is causing this white bar issue. We are working on trying to reproduce with the newer controller and will fix the problem there.

If you have the time, we would of course *love* help getting this upgraded firmware to feature parity with the current firmware so we can switch over ASAP. We are doing the work in the repository at https://github.com/enjoy-digital/opsis-soc/tree/hdmi2usb. This firmware can *not* currently be used for recording but it is getting very close to being able to do that. To work on this repo, use the following script -> https://gist.github.com/mithro/604da515edc1061a77a8ee6c1fe729e6

We also have a long term goal of porting Linux to the LM32 architecture. This is a "fun" thing that people could definitely help out with but is not really on the "critical path". 

  * We can reuse a lot of the Linux kernel infrastructure like the EDID and DisplayPort processing (plus all the workarounds for broken monitors and other hardware).
  * Most of the non-timing critical features can be done in user space, opening up the ability for more people to help out.
  * In theory it could run Debian (very slowly :).

Joel 'shenki' Stanley is currently working on rebase the ancient port onto a modern kernel version and would definitely love help (https://github.com/shenki/linux-lm32/wiki). There are options like qemu and verilator which allow this work to be done without needing access to the actual hardware. If you know any kernel developers who are interested in helping out please do point them our way.

Hope everyone has huge amount of fun!

Tim 'mithro' Ansell

PS It seems like I might be visiting Germany in late December. I'd love to come say Hi to people anywhere in Europe (it's a long flight from Australia), so send me an email if you want to hang out.

PPS We would love to have people come to Linux.conf.au 2017 in Hobart in January. We will be having a TimVideos sprint the week before the conference too.

Reply to: