MikroBUS Patches Being Worked On For Better Supporting These Add-On Boards Under Linux

[phoronix]

Phoronix: MikroBUS Patches Being Worked On For Better Supporting These Add-On Boards Under Linux

MikroBUS is the open add-on board standard aiming for "maximum expandability with the smallest number of pins". MikroBUS already has fairly robust industry support particularly in the embedded space while finally a mikroBUS mainline kernel driver may be near for Linux to improve the status quo of driver support...

http://www.phoronix.com/scan.php?page=news_item&px=MikroBUS-Linux-Driver-Patches

[Brane215]

Is it worth including into kernel sources ?

This is meant for deeply specialized embedded. And IMHO it's not that great. AFAICT it's methodic pin useage for connecting peripherals to micro, at least MIPS ( PIC32 etc).

I never saw great use of that. THose connectors were there mostly just to annoy me.
In MCU owrld one is expected to conquer the learning curve and using available I/O resources is definitely on the bottom of that.

If anyone wants to autoamate that, fine, but why loading official sources with it ?
So that wannabees could set up vibrator driver in 5 instead of a 15 min ?

[starshipeleven]

AFAICT it's methodic pin useage for connecting peripherals to micro, at least MIPS ( PIC32 etc).

It's for Linux, not for microcontrollers, and it provides " SPI, I2C, UART, PWM, ADC, reset, interrupt, and power (3.3V and 5V) connections".

In MCU owrld one is expected to conquer the learning curve and using available I/O resources is definitely on the bottom of that.

in MCU world one is expected to buy a MCU that has enough I/O for the project, and is also powerful enough to run the software. If you must use assembler to make it run fast enough, or you are limiting the I/O because your hardware is limited, you are using the wrong MCU.

If anyone wants to autoamate that, fine, but why loading official sources with it ?

It's a module, won't be compiled or used unless selected.

[Brane215]

in MCU world one is expected to buy a MCU that has enough I/O for the project, and is also powerful enough to run the software. If you must use assembler to make it run fast enough, or you are limiting the I/O because your hardware is limited, you are using the wrong MCU.

Langauge selection is orthogonal to this question. AFAICT this is just automation of selection I/O pins and selecting of registere set to match particular MikroBus assertions, which are subset of values that MCU makes availabe.

So, each MikroBus options is just a few pinselect and generic register initialisations and macros. UART1 to UARTN registers are practically mirror image, so often only thing that is needed, is address of UART base register. Others related registers are at equal offset to base.

So, we'll get particular implementation of available resources in generic vanilla kernel. What is to stop million of other implementation of the same thing ?
Had MikroBus been used en mass, maybe they'd have the case, but as it is now, it seems inappropriate for vanilla kernel.

[starshipeleven]

AFAICT this is just automation of selection I/O pins and selecting of registere set to match particular MikroBus assertions,
....
So, we'll get particular implementation of available resources in generic vanilla kernel. What is to stop million of other implementation of the same thing ?

Yes it is just assigning I/O pins to stuff, and you can do the same with dts or dts overlays.
The main selling point of this protocol is that it autodiscovers what each MikroBus device can do in a dynamic way.

Each module will store its config onboard and send it over when required. Linux upstream will not have to store a table of 750+ hardware definitions for the pinout of each of the current MikroBus modules, anyone can manufacture Mikrobus modules that will "just work" (tm) without having to upstream anything to Linux.

As stated in the patch,

"The manifest binary is now fetched from an I2C EEPROM over the I2C bus on the mikroBUS port(subject to change in mikroBUS v3 specification) and enumerate drivers for the add-on devices.There is also ongoing work to define a mikroBUS v3 standard in which the addon board includes a non-volatile storage to store the device identifier manifest binary, once the mikroBUS v3 standard is released, the mikroBUS can be seen as a probeable bus such that the kernel can discover the device on the bus at boot time."

Had MikroBus been used en mass, maybe they'd have the case, but as it is now, it seems inappropriate for vanilla kernel.

Catch-22. It cannot be used en-masse unless it is convenient to use, to be convenient to use and easily available/maintained it needs to be in vanilla kernel.

[Brane215]

MikroBus is hardly innovative nor generic. So it's just a tiny sliver in infinite pool of possible implementations.
It also isn't de-facto standard in any way.

The fact that it might spare a few option ticks hardly justifies it being packed with a generic kernel, where MIPS is tiny part of its architectures, its Linux supporting part even smaller ( PIC 32MZ) and within those MikroBus will affect perhaps 1% of all users.

That being said, with all the noise about Rust being accepted member of kernel languages, maybe this would be the right time to adopt its cargo packager, perhaps in some more advanced versions. So one could have kernel vanilla crate, which would depend on subcrates to the needed level.

They could agree to official mechanism of synchronisation, so that at the time core crate issues new version X.Y.Z, all the synhronized subcrates would offer the same version of whatever they contain. This would be an equivalent of checking out desiered version of git repository, but subcrates would have much more freedom and users would bother just with crates that are relevant to them.

[starshipeleven]

MikroBus is hardly innovative nor generic.

Not seeing how it isn't generic.
What other protocols like this are in the Kernel? Afaik the only other is Greybus but it is much bigger and meant for more complex modules that need more than just a few I/O pin definitions.

It also isn't de-ćfacto standard in any way.

Catch-22. It cannot be a de-facto standard unless it is convenient to use, to be convenient to use and easily available/maintained it needs to be in vanilla kernel.

The fact that it might spare a few option ticks

No, it spares having to use 750+ dts overrides, and keeping them as separate patch. Or hacking the dts.

MIPS is tiny part of its architectures, its Linuix supporting part even smaller ( PIC 32MZ) and within those MikroBus will affect perhaps 1% of all users.

It's not limited to MIPS. Why the fuck should it even be limited to specific arch? It's basically just reading stuff from i2C and then manipulating hardware definitions.

That being said, with all the noise about Rust being accepted member of kernel languages, maybe this would be the right time to adopt its cargo packager, perhaps in some more advanced versions. So one could have kernel vanilla crate, which would depend on subcrates to the needed level.

Useless fapping, none cares.

[wizard69]

Langauge selection is orthogonal to this question. AFAICT this is just automation of selection I/O pins and selecting of registere set to match particular MikroBus assertions, which are subset of values that MCU makes availabe.

What is interesting here is that I have never heard of this bus before reading the article today. Of course that generated a bunch of interest and a trip to the web site. To be honest the ""standard"" looks like a mess! For one why implement three different serial bus ports on such a physically limited board?

So, each MikroBus options is just a few pinselect and generic register initialisations and macros. UART1 to UARTN registers are practically mirror image, so often only thing that is needed, is address of UART base register. Others related registers are at equal offset to base.

So, we'll get particular implementation of available resources in generic vanilla kernel. What is to stop million of other implementation of the same thing ?
Had MikroBus been used en mass, maybe they'd have the case, but as it is now, it seems inappropriate for vanilla kernel.

Well that is a good question. Maybe something good would come of this. One of the good things that PCI and USB implement is a standardized way to enumerate a bus and the devices connected to it. If this effort results in a standard that more rational board implementations can use it very well might be a good addition to the kernel.

By the way this board format might be great for embedded use, in a lab but I'd be reluctant to use it in most other applications. One issue that popped into my mind is the lack of any sort of board retention solution beyond friction of the socket. The next thing and related, is the over hung nature of the long format boards. Both of these leave me concerned about the board staying in place in many industrial settings. Now those are mechanical issues, the use of three different serial port standards doesn't exactly fill me with love either.

[Brane215]

It's not limited to MIPS. Why the fuck should it even be limited to specific arch? It's basically just reading stuff from i2C and then manipulating hardware definitions.

I've seen them on a couple of PIC32 boards I had and I knew MikroElektronika was adopted by Microchip as 3-rd party source of devboards.
Since MC has been running MIPS on 32-bit end, i thought it was just for MIPS.

If this is to be some SW convention like DDC is for monitors or that XPE-thing is for RAM sticks, that might be generically useable...

[starshipeleven]

I've seen them on a couple of PIC32 boards I had and I knew MikroElektronika was adopted by Microchip as 3-rd party source of devboards.

It's used in ARMv7 boards by SolidRun https://developer.solid-run.com/?s=m...search=1&lang=
and other ARM stuff like BeagleBoard (with an adapter that remaps the pins into 4 sockets.
There is also a hat for the Raspberry Pi.

I guess they are trying to get into the simple Linux embedded usecases with these modules.
Working with modules like that is a godsend for low-production-run projects, where you can't afford to design complex custom boards.