Compiling uboot.img

[obot]

I think I may be missing something in trying to build a uboot.img matching the functionality of the one included with MiSTer. Here's what I've done:

0. I followed the kernel compilation instructions to checkout a working ARM toolcahin that has no problem compiling the kernel, and for uboot I've cloned the latest u-boot_MiSTer repository

1. make MiSTer_defconfig
2. make
3. copy u-boot-with-spl.sfp to /media/fat/linux/uboot.img on the MiSTer and ./updateboot

The new SPL + uboot does indeed get installed and boots the kernel and MiSTer just fine. The only problem is that upon trying to reboot, it hangs instead of rebooting with no difference in dmesg output from the stock uboot.img. I figured I'd ask before trying to track down the issue. The only noteworthy thing I noticed is that the uboot.img I build is ~3kb smaller than the stock one. Is there some secret sauce I'm missing?

Thanks!

Update: this problem has been solved, and the procedure for compiling u-boot for MiSTer is documented in the wiki at https://github.com/MiSTer-devel/Main_Mi ... for-MiSTer. It turned out that for reasons unknown at the moment, compiling u-boot is sensitive to the version of GCC being used to compile it.

[obot]

It turns out the issue is entirely within u-boot and has nothing to do with the linux kernel.

Summary of the issue: Building from https://github.com/MiSTer-devel/u-boot_MiSTer results in a uboot.img where the "reset" u-boot command hangs without further feedback.

The last commit to the above repository is Apr 3rd, 2018, while the stock uboot.img was built on May 23rd, 2018. Is it possible there is a missing commit to the repository? For what it's worth, when I build u-boot from the latest version at https://github.com/u-boot/u-boot, I can build an image where "reset" works fine.

For context, I'm porting a linux driver to enable Wii/NES/SNES Classic controllers directly using I2C through the LTC connector on the DE10-Nano. The stock kernel uses linux's bit-banged I2C-over-GPIO driver for SMBUS compatibility, and the SOC's built-in designware I2C allows polling with much less CPU overhead. The latter requires rebuilding u-boot to configure the pin mux for I2C through the LTC connector. Since I'm still tweaking the driver, being able to reboot without power cycling is very useful.

My SNES Classic controller works great BTW, with around 3ms latency to Linux on the HPS, and I believe this can be further improved.

[Sorgelig]

u-boot repository is correct and latest.
there were no changes in u-boot long time. binary just built time after time while developing that's why it may have recent compilation time.
i2c bit-banging is required for SMBUS compatibility as you said and used for battery monitoring in embedded projects.
i2c on MiSTer never intended for high speed connections and especially for input controllers.
1ms latency adapter you can make using standard Arduino Micro through USB connection.
No need to invent the wheel.

[obot]

Thanks for confirming the u-boot repository is up to date, Sorgelig.

I agree that a Wii accessory to USB adapter is good solution, but it was appealing being able to connect my SNES classic controller just using stuff I had around the house. I also appreciate the elegance of using what's on the DE10 without having an extra adapter in the mix, and I enjoyed working on the kernel driver.

The controller itself seems to have ~1.5ms latency, and the Raphnet USB adapter yields an overall latency of ~1.8ms (per the Mister Addons Google Doc).

[Sorgelig]

Why you need to use raphnet with unknown firmware and how it's tweaked?
Arduino Micro with opensource firmware is much better. You even can tweak FW for your liking.

[obot]

Personally, I'm satisfied with the onboard I2C solution, so I don't need Raphnet or an Arduino Micro. The GPIO driver was using 25% of the HPS core 0, but the Designware version has negligible CPU usage. By faster polling, I can get it down to < 2ms. Now, the only thing is to get reset working. I may just prepare a MiSTer-compatible version of the latest u-boot, where reset works for me.

For someone who wants a solution:

1. Spend $30 for Raphnet, which is the best ready made option I know of. Good but expensive and closed source, as you point out. Other commercial options are also a possibility.

2. Try an Arduino Micro or other DIY MCU solution. DaemonBite would require a bit of extra work to get I2C going. In fact on the Mister Addons spreadsheet, the only tested option for SNES classic controllers is Raphnet. I have an extra STM32 board laying around and considered it, but I went with the below option in the end.

3. The onboard I2C solution -- you just wire 4 pins to the LTC header (assuming you're not using the RTC or Pi-top modules). You don't even need pull-ups per se, since the Nintendo-brand Wii accessory devices have reasonable built-in ones. If you need SMBUS, then 25% usage on HPS core 0 is fine, since MiSTer still gets the other core. If not, then things are even better using the Designware approach. The standard 100khz I2C bus speed is fine in either case.

[Sorgelig]

DaemonBite would require a bit of extra work to get I2C going.

https://github.com/MiSTer-devel/Retro-C ... rollersUSB
It works fine. No extra work required besides connecting the connector to the board.
I use it for my NTT gamepad. I've integrated the whole arduino inside the controller, so now it's generic USB gamepad with many buttons.

[obot]

Sorgelig, the controllers I'm referring to are ones that have connectors that plug into the Wiimote (e.g., see http://wiibrew.org/wiki/Wiimote/Extension_Controllers). In particular, I'm using the controllers that come with the SNES/SFC Classic: e.g., https://en.wikipedia.org/wiki/Super_NES ... m_-_CF.jpg. These are very high quality controllers on par with the original SNES controllers.

The cool thing about these is that they're native I2C controllers, which is why I started this project -- so folks with these controllers can connect them directly to the DE10 LTC connector, without having to buy an adapter or modifying the controller in any way. In addition to the SNES/SFC Classic controllers, Nintendo has produced a NES Classic controller (https://en.wikipedia.org/wiki/NES_Class ... umfang.jpg), and also a few other "classic controllers" during the Wii era using the same connector: https://en.wikipedia.org/wiki/Classic_Controller. The latter controllers are interesting as they also have analog sticks (I own one of these too).

In fact Nintendo has released the source to the Linux I2C driver they use in the NES/SNES/SFC Classic to drive these controllers, and mine is based on this with additional tweaks and improved polling infrastructure. The original source is available at https://www.nintendo.co.jp/support/oss/, and there is a modified version by ClusterM used in the Hakchi project: https://github.com/TeamShinkansen/Hakch ... lovercon.c.

I hope we're on the same page now. The NTT pad is neat -- I hadn't heard of it before.

BTW, I have a fix for the reset issue with u-boot. Turns out that building with a 4.x or 5.x Linaro toolchain produces a uboot.img where reset works, but 6.x and 7.x do not! For reference, the stock uboot.img is compiled with crosstool-NG linaro-1.13.1-4.8-2014.04. This should be documented somewhere. I'm happy to do a short wiki page on compiling u-boot.

[Sorgelig]

Saving $3-$5 in favour to have custom u-boot and kernel looks odd. Especially with USB you can connect more than one gamepad.
Even Wii extension can be easily supported by Arduino Micro. Just no one cared of that.
There are many original USB and Wireless high quality gamepads without needing any special adapters.

[obot]

(1) This isn't about money for me. I wanted to learn more about enabling HPS features via device trees, Linux kernel drivers, etc. This was way more interesting to me than programming an Arduino. In the process I also learned about the HPS/FPGA interaction and some other things I didn't know before. As with many others, this is just a hobby, and it's all about how to make my valuable "free" time satisfying and enjoyable. I'm probably preaching to the choir here.

(2) Now that I'm done with the project, others can benefit from my work. Again, preaching to the choir

As noted above, the driver works fine with the existing GPIO I2C, and updates the state of the controller every ~3ms this way (overall latency on par with the recommended DS4 rev 2). If we commit the kernel driver to the MiSTer kernel repository, then it's no longer "custom," and this requires no special u-boot. It checks at boot time for the presence of a controller, and if it's not there, it doesn't load. The only downside might be 15-25% usage on HPS core 0, but this doesn't affect MiSTer in any noticeable way.

If someone wants better latency (~1ms state updates) and doesn't need SMBUS, one can build the custom u-boot and kernel (or download a binary that I can provide), which is pretty easy now that we know to use an older version of the toolchain. I could write the kernel controller driver so it checks to see which I2C adapter is being used (GPIO or Designware) and installs the appropriate polling routine, so that only the kernel device tree would have to be modified. Maybe it's possible to do everything on the kernel side dynamically, so that only u-boot needs to change?

Anyway, the point here is that this offers folks a choice. No one would be required to use a custom u-boot/kernel in order to use the controller.

(3) So if we commit the driver (using GPIO I2C for now), anyone who happens to have Wii extension controller can use it without necessarily buying anything else or programming anything else. I completely agree with you that this only supports one controller (the HPS does have more I2C modules, but they may not be connected to header pins on the DE10 -- I haven't checked).

I also agree that there are lots of great controllers out there, but this gives folks yet another option. I love using a wired genuine Nintendo SNES controller, that isn't decades old, with the SNES core! I already owned a pair, and they were basically brand new -- icing on the cake. I imagine others own a FC/NES/SFC/SNES Classic and also dipped into MiSTer. These people would now have an easy and excellent option for using their controllers. I own maybe 15-20 controllers from the 1990s to present that work with MiSTer, and the SNES Classic controller is one of my top choices (probably nostalgia).

Summary: I consider this project finished, and this was definitely the right choice for me. I'm happy to clean things up and initiate a pull request for the GPIO I2C-compatible kernel driver, otherwise I'm equally happy having done this just for myself.

[Sorgelig]

Linux and open source give a lot of choice what you can make. It doesn't mean it should be included.
As you've told it was fun for you to make something and see the success. That's fine.
It's just has no practical usage as it requires either custom u-boot and kernel or 25% CPU usage. And only single device is supported. PSX controllers for example use bus very similar to SPI. It doesn't mean MiSTer should support it too.
Also i really doubt that random user has Wii extension connector laying around. Or you suggest to cut the cable?
It would be quite helpful if you would make arduino micro project supporting Wiimote extensions. But i guess it's not interesting project for you.

[obot]

These are all fair points, Sorgelig. Yup, the guarantee I have with open source is that I can customize things the way I like, not that my customizations will make it upstream and be maintained by others -- acknowledged.

I agree that neither option is elegant, using CPU time for polling is ugly, and so is a customized u-boot/kernel (and the potential incompatibilities with SMBUS I2C applications). However, I can see an argument for including the former option. For those that don't care to use the controller, this driver will do nothing, and it's there for those that just may want to use it and are OK with the CPU usage (the core is mostly idle anyways). It's akin to the situation with the pi-top -- every MiSTer install currently has code that checks if a pi-top battery interface is on the I2C bus, but very few actually use it. What fraction of MiSTer users have pi-tops? What fraction would be interested in Wii extension controllers (in a world where commercial options are the only readily available alternatives)?

To answer your question, I settled on a Wii-extension extension cable that I cut and coupled with an IDC connector (the 2.0mm pitch on the LTC header is annoying). I started prototyping with one of these: https://www.ebay.com/p/1648420917.

I think we both agree that Wii extension controller support is interesting (e.g., as noted it's still the only way to get wired, genuine Nintendo controllers that aren't decades old). You feel that most people would prefer the arduino micro option, all else being comparable. I actually would take the 25% CPU usage over the arduino. I hate the clutter of having an extra USB board/device and much rather prefer the cable I have where one end plugs directly into the LTC connector. To each their own of course.

In fact I have a micropendous (from back when Arduino weren't as popular/powerful, https://code.google.com/archive/p/micro ... _32U2.wiki), and I indeed did a Wii extension to USB HID project maybe 9 years ago. I considered resurrecting this but ultimately find having a single cable over having an exposed PCB + extra cables more appealing (I don't have an interest in making a case since the device would still take up space).

I'm not necessarily advocating one way or the other for including the driver, but I do want to make sure all the arguments have been made (e.g. the comparison to pi-top above). If it matters, I recall be able to decrease the CPU usage to 10-15% without an appreciable hit in latency (by using a different polling method); I'll go back and check. In short, I don't think the CPU usage is necessarily the issue to focus on; I intended for the polling rate to be user configurable anyway.

[Sorgelig]

I don't remember exactly, but as far as i remember extension port is supported through standard BT connection if you use wiimote itself. Because i worked with 2 implementations of wiimote driver, one (or both) supported all connected extensions i've tried. Sure, latency will be higher, but not all are obsessed by low latency. Do you know that human "latency" is much more than 100ms?
Anyway, there are at least 2 ways to use wiimote extensions without intervention into MiSTer internals. Actually i'm not that excited with wiimote extensions quality. Analog sticks have pretty bad resolutions.

[obot]

Yup, I do also believe extension port is supported through a wiimote over BT. I agree that the former or acquiring a USB-to-extension-port adapter is a reasonable set of options providing different tradeoffs. I can also understand the reluctance in adding another, possibly untested, kernel driver (though, if this is your primary concern, the clvcon.c driver Nintendo uses in their classic consoles can be made to compile and work as-is for MiSTer without the modifications I've made, with negligible CPU usage if super low latency isn't a concern).

I think we've covered all the bases, and it looks like you'd prefer to leave things as is. Sounds good to me.

BTW, the last time I looked into perception of latency, I came away with ~100ms makes a system feel unresponsive to humans, and ~50ms is noticeable (with appreciable variance from person to person). There's also the difference between reaction time to an unexpected stimulus vs lag in an expected outcome to consider. The first post here is a simple way to test your tolerance for the latter: https://news.ycombinator.com/item?id=15486494.