Re: VirtIO MMIO for amd64
Update My NetBSD/amd64 branch can now boot using PVH on qemu/x86_64, qemu/microvm and Firecracker using MMIO backed block devices. It also supports multiple VirtIO devices such as NICs. The last blocking point was that Firecracker only supports one data segment and as such needs DMA bouncing which was not enabled for that case (thanks Jason for the hint!). Now before opening a PR I'd like your advice on the "cmdline bus" part. As I explained earlier in this thread, without PCI or ACPI, MMIO devices are "detected" through a kernel parameter, for example: root=ld0a console=com rw -v virtio_mmio.device=512@0xfeb00e00:12 virtio_mmio.device=512@0xfeb00c00:11 To support this, I've attached `virtio*` to a newly created bus, `cmdlinebus?` which is attached to mainbus in amd64_mainbus.c I am not entirely sure this is the cleanest way to proceed and would like to have your feedback. The working branch is here: https://github.com/NetBSDfr/NetBSD-src/tree/mmio_cmdline Cheers, -- Emile `iMil' Heitor | https://imil.net
Re: Polymorphic devices
Brad Spencer wrote : > It has a built in UART which is a separate USB device and then > a USB device that can be programmed to provide I2C, What are you using to flash these devices? I have been using several I2C devices such as servomotor controllers, i/o extenders, relay controllers, displays, etc. with arduino controllers (waiting on some esp32 boards now) and most of the non-standard arduino boards require flashing (via usb) of some sort to set what you want to use, as I will have to so with the esp32s. I am having to use a 10-yr-old windows laptop to flash and program these things. I wish we had the Arduino IDE ported to NetBSD as it is a very nice tools for this but waiting for 10 minutes for the thing to come up under windows is tiring. Once they are up, many of these controllers have bluetooth, ethernet and wifi support where I can control them directly from NetBSD but getting them there and programming them is archaic on windows. Yes, there are the basic programmers in pkgsrc but the arduino ide can easily program a complete package linked to a git repository into these devices very nicely (once you have it up and running) and runs on linux. Having I2C devices directly accessible sounds interesting though.
Re: Polymorphic devices
Greg Troxel writes: > Brad Spencer writes: > >> The first is enhancements to ufdti to support the MPSSE engine that some >> of the FTDI chip variants have. This engine allows the chip to be a I2C >> bus, SPI bus and provides some simple GPIO, and a bunch of other stuff, >> as well as the normal USB UART. It is not possible to use all of the >> modes at the same time. That is, these are not separate devices, but >> modes within one device. Or another way, depending on the mode of the >> chip you get different child devices attached to it. I am curious on >> what the thoughts are on how this might be modeled. > > My reaction without much thought is to attach them all and to have the > non-selected one return ENXIO or similar. And to have another device on > which you call the ioctl to choose which device to enable. > > Or perhaps, to let you open any of them, flipping the mode, and to fail > the 2nd simultaenous open. Those techniques and models have occured to be too, except I probably would still elect to use use a sysctl instead of another device with a ioctl. I don't know just yet, but there might be unwanted device reset the "use the one you open" technique. That is, you might have to reset the chip to change mode and if you support say, I2C and GPIO at the same time (which is possible), but then change to just GPIO the chip has to be reset and that will disrupt any setting you might have set (I think, I am am still working out what needs to happen with the mode switches). This may not matter in the bigger picture and it wouldn't matter as much if the mode switch was a sysctl, which one can say will reset the chip anyway. In any case, thanks for the comments... -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Polymorphic devices
Brad Spencer writes: > The first is enhancements to ufdti to support the MPSSE engine that some > of the FTDI chip variants have. This engine allows the chip to be a I2C > bus, SPI bus and provides some simple GPIO, and a bunch of other stuff, > as well as the normal USB UART. It is not possible to use all of the > modes at the same time. That is, these are not separate devices, but > modes within one device. Or another way, depending on the mode of the > chip you get different child devices attached to it. I am curious on > what the thoughts are on how this might be modeled. My reaction without much thought is to attach them all and to have the non-selected one return ENXIO or similar. And to have another device on which you call the ioctl to choose which device to enable. Or perhaps, to let you open any of them, flipping the mode, and to fail the 2nd simultaenous open.
Polymorphic devices
Hello I am in need of some advise and guidance. I am working slowly on device support for a couple of USB chips that have multiple, but somewhat mutually exclusive, behaviors. The first is enhancements to ufdti to support the MPSSE engine that some of the FTDI chip variants have. This engine allows the chip to be a I2C bus, SPI bus and provides some simple GPIO, and a bunch of other stuff, as well as the normal USB UART. It is not possible to use all of the modes at the same time. That is, these are not separate devices, but modes within one device. Or another way, depending on the mode of the chip you get different child devices attached to it. I am curious on what the thoughts are on how this might be modeled. I see a few options for doing this, such as simply matching all of the possible children and using sysctl to enable the one you want. Probably followed by a rescan call. That seems ugly, however. The use of 'drvctl -r -a ' seemed to hold promise. It seems like a better idea to require the detachment of whatever followed by the rescan with the attribute indicating which sort of thing you wanted to attach (detach ucom in favor of i2c, for example). But I do not completely understand if this sort of thing is possible. The second chip is the MCP2221 which provides some of the same features as the FTDI MPSSE engine. It has a built in UART which is a separate USB device and then a USB device that can be programmed to provide I2C, GPIO, some DAC a bit of ADC (low number of bits in both of those cases, but still interesting enough). You can probably always just provide the I2C bus and then flip the behaviors of the GPIO pins by setting their alt settings. This chip may be a bit simpler to deal with with the using gpio alt settings and such, but I also have not looked at this one as much. If I can get these to work, the end result will be that any system with USB, including virtual systems with USB devices presented to it in some way, can have I2C, simple GPIO and maybe SPI ... and this is the place I want to end up for my own needs. I have looked around the tree for other devices that do this sort of thing and didn't really find any that tried to deal with this sort of situation, but I will admit I looked mostly at the MI devices. Any thoughts would be appreciated, -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
