The idea: - make it very easy to create hardware gadgets by providing a firmware/hardware building block that talks 9p on the host interface side & interfaces with device specific hardware. - use a "universal" 9p driver on the host side that allows access to any such 9p device even from a shell. - provide a standard way to find out device capabilities. - together they provide a plug-and-play setup. Example: connect an LED and a current sensor to this 9p device, other necessary hardware, add a few config bits and plug this device kn]]into a host. Now you should be able to turn on/off the light or sense its state. Similarly you should be able to control a stepper motor servo, cameras, microphones, other actuators, sensors, IO etc. Eventually you should be able to snap together enough of these components to build larger assemblies such as a 3D printer. Another example: a "hub" to multiplex such downstream devices and make them available to a host. This will probably have to ride on USB first. A verilog implementation would be useful in an FPGA! Would this be a useful component? If such a thing were available, what would you want to build with it? Do you think 9p is the right protocol for this? Ideally - connect anything to anything - authenticated connections - drive the device through a shell script - no new low level drivers - self-identifying devices with help and command syntax - signicantly eases the task of creating new h/w devices. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M35165d4278d95e41fd95b8f7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 3289 bytes --] I've been saying the same thing for years. 9p makes for a great control protocol that presents a simple way to present data, a tree of files. Charles Forsyth wrote an Atmega compiler for plan 9. That could be used as the basis for a plan 9 Arduino thing. We likely need a mulibc.h or whatever and a loader to send the binary to the Arduino micro controller. Someone patched 9front usbserial to recognize Arduino USB boards as usbeia devices. (I think Miller's pi and labs does too?). Out of the box microcontroller support with 9p libs would be a really nice thing to have. Echoline wrote ninepea, an Arduino 9p library. This currently works and can be mounted on a plan 9 machine and you can talk to your Arduino though files. Though this uses the official Arduino library and compiler which does not work on plan 9 (on 9front you can use vmx to run a Linux vm) One compiler that we really need is an arm thumb 2 compiler for cortex-m/r microcontrollers. Inferno has a very old and very incomplete arm thumb 1 compiler, tc. I don't know if it's worth salvaging. Personally, I'm (sloooowly)working on using Plan 9 for personal industrial automation projects. I have some crude modbus stuff working. At work I've used it on a RasPi to tie a PLC to an HDMI heads up display that uses ASCII commands. Dumb easy to write a C program for that on Plan 9. On Thu, Jan 27, 2022, 5:58 PM Bakul Shah <bakul@iitbombay.org> wrote: > The idea: > - make it very easy to create hardware gadgets by > providing a firmware/hardware building block that > talks 9p on the host interface side & interfaces > with device specific hardware. > > - use a "universal" 9p driver on the host side that > allows access to any such 9p device even from a shell. > > - provide a standard way to find out device capabilities. > > - together they provide a plug-and-play setup. > > Example: connect an LED and a current sensor to this > 9p device, other necessary hardware, add a few config > bits and plug this device kn]]into a host. Now you should > be able to turn on/off the light or sense its state. > > Similarly you should be able to control a stepper motor > servo, cameras, microphones, other actuators, sensors, > IO etc. Eventually you should be able to snap together > enough of these components to build larger assemblies > such as a 3D printer. > > Another example: a "hub" to multiplex such downstream > devices and make them available to a host. > > This will probably have to ride on USB first. A verilog > implementation would be useful in an FPGA! > > Would this be a useful component? If such a thing were > available, what would you want to build with it? > > Do you think 9p is the right protocol for this? > > Ideally > - connect anything to anything > - authenticated connections > - drive the device through a shell script > - no new low level drivers > - self-identifying devices with help and command syntax > - signicantly eases the task of creating new h/w devices. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Md8f444a123a5bc9a248fbb72 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 5073 bytes --]
On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: > The idea: > - make it very easy to create hardware gadgets by > providing a firmware/hardware building block that > talks 9p on the host interface side & interfaces > with device specific hardware. > > [ ... ] > Sounds very appealing. There's a UEFI-based development that puts 9P2000 inside the modern BIOS - excuse the imprecise language: I played with it and my ignorance caused me to get frustrated before I could accomplish anything with it. I'll dig up a github reference if anyone asks. I found it while searching for something quite different. > This will probably have to ride on USB first. A verilog > implementation would be useful in an FPGA! > I never understood why USB receives so much attention (but thanks to all those who valiantly tried to tame that wild beast!). What does it do that PoE doesn't do infinitely better? > Would this be a useful component? If such a thing were > available, what would you want to build with it? > What I would want from such a tool is its availability within educational institutions so we stop teaching greed technology to learners and lower the knowledge entry bar that Intel and Microsoft - and their allies - have created (that, I make no apologies for, is Politics, the Politics of Technological Domination). Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Ma773a08b767b5dc5e0cf85f4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Bakul Shah <bakul@iitbombay.org>: > The idea: > - make it very easy to create hardware gadgets by > providing a firmware/hardware building block that > talks 9p on the host interface side & interfaces > with device specific hardware. > > - use a "universal" 9p driver on the host side that > allows access to any such 9p device even from a shell. > > - provide a standard way to find out device capabilities. > > - together they provide a plug-and-play setup. > > Example: connect an LED and a current sensor to this > 9p device, other necessary hardware, add a few config > bits and plug this device kn]]into a host. Now you should > be able to turn on/off the light or sense its state. > > Similarly you should be able to control a stepper motor > servo, cameras, microphones, other actuators, sensors, > IO etc. Eventually you should be able to snap together > enough of these components to build larger assemblies > such as a 3D printer. > I did something like this at a previous job, where we had firmware exposed via 9p tunneled over a USB bulk endpoint. The firmware was implemented on an STM32, and mounted from linux using lib9pclient with a p9p-ectomy. It worked quite well. Unfortunately, it wasn't open source, and the company is now dead. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M3bb33fdcb2c2e0c5bb8ca717 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Jan 27, 2022, at 7:31 PM, Lucio De Re <lucio.dere@gmail.com> wrote: > > On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: > >> This will probably have to ride on USB first. A verilog >> implementation would be useful in an FPGA! >> > I never understood why USB receives so much attention (but thanks to > all those who valiantly tried to tame that wild beast!). What does it > do that PoE doesn't do infinitely better? Think of really simple, low power, low cost devices. USB can also provide power. USB+ATtiny85 devel boards cost ~$3 even at Amazon. And FPGA boards can be pretty inexpensive too. If you can find them. But note these are just preliminary ideas. >> Would this be a useful component? If such a thing were >> available, what would you want to build with it? >> > What I would want from such a tool is its availability within > educational institutions so we stop teaching greed technology to > learners and lower the knowledge entry bar that Intel and Microsoft - > and their allies - have created (that, I make no apologies for, is > Politics, the Politics of Technological Domination). Let us first build a few before worrying about such things. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M7612c07b44c6a417cec5c3ba Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: > > Think of really simple, low power, low cost devices. > USB can also provide power. USB+ATtiny85 devel boards > cost ~$3 even at Amazon. And FPGA boards can be > pretty inexpensive too. If you can find them. > I've recommended olimex.com in the past. They specialise in Open Architecture Hardware. Their prices are very reasonable and product range quite broad. Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M84956412e025f5666616e7cd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --] https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf might be of interest. They turned up at an embedded systems show at Birmingham NEC about that time. I was attending independently, but it was interesting to see,. Wandering about some boring other stands, I found one that was showing off a small embedded device running a remarkable system. There was source code on the screen. "Hmm", I asked, "what's the language it's running?" Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on a micro with a real-time garbage collector and in-service code updating on the fly. Just fantastic. We bemoaned the boring nature of most of the stands. I mentioned Styx-on-a-Chip and he wandered off to have a look, returning to say it was also interesting. I forget the name of the system, but eventually the company was sold on or got different investors in, who turned it into a Java thing. As usual. On Fri, 28 Jan 2022 at 10:18, Lucio De Re <lucio.dere@gmail.com> wrote: > On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: > > > > Think of really simple, low power, low cost devices. > > USB can also provide power. USB+ATtiny85 devel boards > > cost ~$3 even at Amazon. And FPGA boards can be > > pretty inexpensive too. If you can find them. > > > I've recommended olimex.com in the past. They specialise in Open > Architecture Hardware. Their prices are very reasonable and product > range quite broad. > > Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mc901f3049ed9f148d9ee00e7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 3324 bytes --]
> What does it do that PoE doesn't do infinitely better? For most of its life USB was only 5 V: https://en.wikipedia.org/wiki/USB#Power PoE is (mostly) 48 V: https://en.wikipedia.org/wiki/Power_over_Ethernet#Standard_implementation PoE also requires the use of either special PoE switches or power injectors, so at the time USB was first created it was cheaper & made more sense for PC and laptop hardware. Also, back then the USB folks were all like "4 different PoE standards?! That's ridiculous!" https://xkcd.com/927/ ;) ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M1400218699cd447169fa0b16 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --] A few years back I started trying to build something similar off of the STM32F4 line of ARM MCUs. https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html Supports ethernet, spi, usb otg, etc. Thought about porting the libstyx library from Inferno over to the STM32 platform. https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest Thin OS layer was provided by FreeRTOS. STM32F4 specific HW was accessed using libopencm3 https://libopencm3.org/ If interested... https://github.com/tmendoza/stm32f4-template Tony On 1/28/2022 at 4:18 AM, "Lucio De Re" wrote:On 1/28/22, Bakul Shah wrote: > > Think of really simple, low power, low cost devices. > USB can also provide power. USB+ATtiny85 devel boards > cost ~$3 even at Amazon. And FPGA boards can be > pretty inexpensive too. If you can find them. > I've recommended olimex.com in the past. They specialise in Open Architecture Hardware. Their prices are very reasonable and product range quite broad. Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M125c9309ccdbe0d7fa4f7bd6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 2936 bytes --]
Bakul Shah writes: > - make it very easy to create hardware gadgets by > providing a firmware/hardware building block that > talks 9p on the host interface side & interfaces > with device specific hardware. Amen! I've been thinking about something like this for years. My specific use case involves controlling radio transceivers. Right now I do this with assorted Arduino hardware that speaks GPIO and RS232 (mostly) to the radios, and RS232 to the upstream "controller" host. This burns through a lot of serial ports on the controller. What I would prefer is to have all those Arduinos connected to an RS485 multidrop, each exporting a 9p filesystem for the control interface. Shoveling the data around on the RS485 "bus" just needs a simple frame wrapped around the 9p packets that provides device addressing and a CRC. On the Plan9 side this just becomes another network type, with ndb handling the device addressing. As others have mentioned, having a native Atmel C compiler would be a real boon here, but there's no reason why this couldn't be done with an Arduino 9P library. I haven't investigated if such a thing exists, although I'm sure it does. --lyndon ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M7e3fd4de0f3c256df6dbd436 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --] Sorry wrong libstyx repo https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx T On 1/28/2022 at 2:54 PM, "Tony Mendoza" wrote:A few years back I started trying to build something similar off of the STM32F4 line of ARM MCUs. https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html Supports ethernet, spi, usb otg, etc. Thought about porting the libstyx library from Inferno over to the STM32 platform. https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest Thin OS layer was provided by FreeRTOS. STM32F4 specific HW was accessed using libopencm3 https://libopencm3.org/ If interested... https://github.com/tmendoza/stm32f4-template Tony On 1/28/2022 at 4:18 AM, "Lucio De Re" wrote:On 1/28/22, Bakul Shah wrote: > > Think of really simple, low power, low cost devices. > USB can also provide power. USB+ATtiny85 devel boards > cost ~$3 even at Amazon. And FPGA boards can be > pretty inexpensive too. If you can find them. > I've recommended olimex.com in the past. They specialise in Open Architecture Hardware. Their prices are very reasonable and product range quite broad. Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M9b55bdb38551719bdce93c4f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 3640 bytes --]
Quoth Tony Mendoza <clueelf@tonymendoza.us>: > Sorry wrong libstyx repo also, this repo is private: > If interested... > https://github.com/tmendoza/stm32f4-template > Tony ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M29773dab50c15f7f2333e215 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --] I started working on a project with an ESP32 board (with a toolchain for linux) to make a /net/etherESP32 for wifi with 9P right on the little board. I got as far as realizing how different 802.11 and 802.3 are... the unfinished code is at https://github.com/echoline/etherESP32 it would be cool to see an aijuboard with accelerated hardware devdraw on the fpga if that's even possible, or other hardware like that On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza <clueelf@tonymendoza.us> wrote: > Sorry wrong libstyx repo > > https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx > > T > > On 1/28/2022 at 2:54 PM, "Tony Mendoza" <clueelf@tonymendoza.us> wrote: > > A few years back I started trying to build something similar off of the > STM32F4 line of ARM MCUs. > > https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html > > Supports ethernet, spi, usb otg, etc. Thought about porting the libstyx > library from Inferno over to > the STM32 platform. > > https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest > > Thin OS layer was provided by FreeRTOS. STM32F4 specific HW was accessed > using libopencm3 > > https://libopencm3.org/ > > If interested... > > https://github.com/tmendoza/stm32f4-template > > Tony > > On 1/28/2022 at 4:18 AM, "Lucio De Re" <lucio.dere@gmail.com> wrote: > > On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: > > > > Think of really simple, low power, low cost devices. > > USB can also provide power. USB+ATtiny85 devel boards > > cost ~$3 even at Amazon. And FPGA boards can be > > pretty inexpensive too. If you can find them. > > > I've recommended olimex.com in the past. They specialise in Open > Architecture Hardware. Their prices are very reasonable and product > range quite broad. > > Lucio. > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M9b55bdb38551719bdce93c4f> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Me6241517a2c3673d4467fc7a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 4934 bytes --]
[-- Attachment #1: Type: text/plain, Size: 523 bytes --] Well that was rude of me ;-) Should be public now. Thanks for the heads up! T On 1/28/2022 at 3:05 PM, ori@eigenstate.org wrote:Quoth Tony Mendoza : > Sorry wrong libstyx repo also, this repo is private: > If interested... > https://github.com/tmendoza/stm32f4-template > Tony ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M2dd37ff2d72250c1301ba95f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 1778 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2154 bytes --] Eli said - "...accelerated hardware devdraw on the fpga if that's even possible" It's possible. https://projectf.io/posts/fpga-graphics/ T On 1/28/2022 at 3:08 PM, "Eli Cohen" wrote:I started working on a project with an ESP32 board (with a toolchain for linux) to make a /net/etherESP32 for wifi with 9P right on the little board. I got as far as realizing how different 802.11 and 802.3 are... the unfinished code is at https://github.com/echoline/etherESP32 it would be cool to see an aijuboard with accelerated hardware devdraw on the fpga if that's even possible, or other hardware like that On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza wrote: Sorry wrong libstyx repo https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx T On 1/28/2022 at 2:54 PM, "Tony Mendoza" wrote:A few years back I started trying to build something similar off of the STM32F4 line of ARM MCUs. https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html Supports ethernet, spi, usb otg, etc. Thought about porting the libstyx library from Inferno over to the STM32 platform. https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest Thin OS layer was provided by FreeRTOS. STM32F4 specific HW was accessed using libopencm3 https://libopencm3.org/ If interested... https://github.com/tmendoza/stm32f4-template Tony On 1/28/2022 at 4:18 AM, "Lucio De Re" wrote:On 1/28/22, Bakul Shah wrote: > > Think of really simple, low power, low cost devices. > USB can also provide power. USB+ATtiny85 devel boards > cost ~$3 even at Amazon. And FPGA boards can be > pretty inexpensive too. If you can find them. > I've recommended olimex.com in the past. They specialise in Open Architecture Hardware. Their prices are very reasonable and product range quite broad. Lucio. 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mb0d91d78bd0ccb6b864611c7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 5254 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3043 bytes --] Thanks! Quite an interesting paper. I vaguely recall reading this a long time ago. I think the key will be to figure out how to make this a very easy to use component. It is not rocket science but will probably require a few iterations to smooth out any rough edges and to see what evolves. Good to see there is interest in the community! > On Jan 28, 2022, at 11:01 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote: > > https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf <https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf> might be of interest. > > They turned up at an embedded systems show at Birmingham NEC about that time. > I was attending independently, but it was interesting to see,. > Wandering about some boring other stands, I found one that was showing off a small embedded device running a remarkable system. > There was source code on the screen. > "Hmm", I asked, "what's the language it's running?" > Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on a micro with a real-time garbage collector and in-service code updating on the fly. > Just fantastic. We bemoaned the boring nature of most of the stands. I mentioned Styx-on-a-Chip and he wandered off to have a look, returning to say it was also interesting. > I forget the name of the system, but eventually the company was sold on or got different investors in, who turned it into a Java thing. As usual. > > On Fri, 28 Jan 2022 at 10:18, Lucio De Re <lucio.dere@gmail.com <mailto:lucio.dere@gmail.com>> wrote: > On 1/28/22, Bakul Shah <bakul@iitbombay.org <mailto:bakul@iitbombay.org>> wrote: > > > > Think of really simple, low power, low cost devices. > > USB can also provide power. USB+ATtiny85 devel boards > > cost ~$3 even at Amazon. And FPGA boards can be > > pretty inexpensive too. If you can find them. > > > I've recommended olimex.com <http://olimex.com/> in the past. They specialise in Open > Architecture Hardware. Their prices are very reasonable and product > range quite broad. > > Lucio. > > ------------------------------------------ > 9fans: 9fans > Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M84956412e025f5666616e7cd <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M84956412e025f5666616e7cd> > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription> > 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mc901f3049ed9f148d9ee00e7> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M3c9ced3c7ccb25fd4918537c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 4843 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2901 bytes --] hmmm. but for all of the devdraw fs and image backing, etc? can it access RAM? On Fri, Jan 28, 2022, 1:18 PM Tony Mendoza <clueelf@tonymendoza.us> wrote: > Eli said - "...accelerated hardware devdraw on the fpga if that's even > possible" > > It's possible. > > https://projectf.io/posts/fpga-graphics/ > > T > > On 1/28/2022 at 3:08 PM, "Eli Cohen" <echoline@gmail.com> wrote: > > I started working on a project with an ESP32 board (with a toolchain for > linux) to make a /net/etherESP32 for wifi with 9P right on the little > board. I got as far as realizing how different 802.11 and 802.3 are... > > the unfinished code is at https://github.com/echoline/etherESP32 > > it would be cool to see an aijuboard with accelerated hardware devdraw on > the fpga if that's even possible, or other hardware like that > > On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza <clueelf@tonymendoza.us> wrote: > >> Sorry wrong libstyx repo >> >> https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx >> >> T >> >> On 1/28/2022 at 2:54 PM, "Tony Mendoza" <clueelf@tonymendoza.us> wrote: >> >> A few years back I started trying to build something similar off of the >> STM32F4 line of ARM MCUs. >> >> https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html >> >> Supports ethernet, spi, usb otg, etc. Thought about porting the libstyx >> library from Inferno over to >> the STM32 platform. >> >> https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest >> >> Thin OS layer was provided by FreeRTOS. STM32F4 specific HW was accessed >> using libopencm3 >> >> https://libopencm3.org/ >> >> If interested... >> >> https://github.com/tmendoza/stm32f4-template >> >> Tony >> >> On 1/28/2022 at 4:18 AM, "Lucio De Re" <lucio.dere@gmail.com> wrote: >> >> On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: >> > >> > Think of really simple, low power, low cost devices. >> > USB can also provide power. USB+ATtiny85 devel boards >> > cost ~$3 even at Amazon. And FPGA boards can be >> > pretty inexpensive too. If you can find them. >> > >> I've recommended olimex.com in the past. They specialise in Open >> Architecture Hardware. Their prices are very reasonable and product >> range quite broad. >> >> Lucio. >> >> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mb0d91d78bd0ccb6b864611c7> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M7c105b558e297b07d1ace778 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 5937 bytes --]
[-- Attachment #1: Type: text/plain, Size: 776 bytes --] On 2022-01-28 2:55:00, Thaddeus Woskowiak wrote: > One compiler that we really need is an arm thumb 2 compiler for cortex-m/r > microcontrollers. Inferno has a very old and very incomplete arm thumb 1 > compiler, tc. I don't know if it's worth salvaging. I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks to some hints from Charles Forsyth. I'm currently trying to add FP support and learn about compiler internals. It also means learning about Thumb-2, which is quite alien for an old-school ARM coder. David ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mf2179e1b0562dfb5ee43b267 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 1486 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2906 bytes --] I also started a paper about the very small 9P library I used on MCUs, I was hoping to present this at IWP9 before we all ended up in the pandemic Biff timeline https://echoline.org/NinePea.pdf this paper is still not that polished yet On Fri, Jan 28, 2022, 1:28 PM Bakul Shah <bakul@iitbombay.org> wrote: > Thanks! Quite an interesting paper. I vaguely recall reading > this a long time ago. > > I think the key will be to figure out how to make this a very > easy to use component. It is not rocket science but will > probably require a few iterations to smooth out any rough > edges and to see what evolves. > > Good to see there is interest in the community! > > On Jan 28, 2022, at 11:01 AM, Charles Forsyth <charles.forsyth@gmail.com> > wrote: > > https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf might > be of interest. > > They turned up at an embedded systems show at Birmingham NEC about that > time. > I was attending independently, but it was interesting to see,. > Wandering about some boring other stands, I found one that was showing off > a small embedded device running a remarkable system. > There was source code on the screen. > "Hmm", I asked, "what's the language it's running?" > Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on > a micro with a real-time garbage collector and in-service code updating on > the fly. > Just fantastic. We bemoaned the boring nature of most of the stands. I > mentioned Styx-on-a-Chip and he wandered off to have a look, returning to > say it was also interesting. > I forget the name of the system, but eventually the company was sold on or > got different investors in, who turned it into a Java thing. As usual. > > On Fri, 28 Jan 2022 at 10:18, Lucio De Re <lucio.dere@gmail.com> wrote: > >> On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: >> > >> > Think of really simple, low power, low cost devices. >> > USB can also provide power. USB+ATtiny85 devel boards >> > cost ~$3 even at Amazon. And FPGA boards can be >> > pretty inexpensive too. If you can find them. >> > >> I've recommended olimex.com in the past. They specialise in Open >> Architecture Hardware. Their prices are very reasonable and product >> range quite broad. >> >> Lucio. > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M3c9ced3c7ccb25fd4918537c> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M90622b7b8d0862975bcbb175 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 4951 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --] Any interest in sharing those hints for building bare metal STM32F405 code om plan9? T On 1/28/2022 at 3:34 PM, david@boddie.org.uk wrote:On 2022-01-28 2:55:00, Thaddeus Woskowiak wrote: > One compiler that we really need is an arm thumb 2 compiler for cortex-m/r > microcontrollers. Inferno has a very old and very incomplete arm thumb 1 > compiler, tc. I don't know if it's worth salvaging. I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks to some hints from Charles Forsyth. I'm currently trying to add FP support and learn about compiler internals. It also means learning about Thumb-2, which is quite alien for an old-school ARM coder. David 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M520003e6d6ac2b54e8e509e4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 1857 bytes --]
I'll try and write something useful about it this weekend, and I'll push a branch up to BitBucket/GitLab: https://bitbucket.org/dboddie/inferno-os/branches/ https://gitlab.com/dboddie/inferno-os/-/branches However, it basically boils down to this: * Build Inferno's tc and tl since they are not included in the default build. * Fix the tl mkfile so that it calls the executable tl not 5l. * Write a mkfile with all the rules for 5a, tc and tl, setting the text address to 0x08000000 (flash) and data to 0x20000000 (RAM). * Write a loader file to set up the stack and static base registers, copy data into RAM, and jump into main. I have some functions for setting up clocks, GPIOs and the USART. This is currently in a separate repository for bare metal tests. I'll push that up to GitLab. David On Friday, 28 January 2022 22:46:28 CET Tony Mendoza wrote: > Any interest in sharing those hints for building bare metal STM32F405 > code om plan9? > T > On 1/28/2022 at 3:34 PM, david@boddie.org.uk wrote:On 2022-01-28 > > 2:55:00, Thaddeus Woskowiak wrote: > > One compiler that we really need is an arm thumb 2 compiler for > > cortex-m/r > > > microcontrollers. Inferno has a very old and very incomplete arm > > thumb 1 > > > compiler, tc. I don't know if it's worth salvaging. > > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU > thanks > to some hints from Charles Forsyth. > > I'm currently trying to add FP support and learn about compiler > internals. > It also means learning about Thumb-2, which is quite alien for an > old-school > ARM coder. > > David > 9fans / 9fans / see discussions + participants + delivery > options Permalink > ------------------------------------------ > 9fans: 9fans > Permalink: > https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M520003e6d6ac2b54 > e8e509e4 Delivery options: > https://9fans.topicbox.com/groups/9fans/subscription ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Me02d5cb4e136e32f9d0015d0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
david@boddie.org.uk writes: > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks > to some hints from Charles Forsyth. Could you post some notes on how you're doing that? This is something I'd like to take for a spin. --lyndon ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mec6e5bd345ad735a072a6cc7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Saturday, 29 January 2022 02:04:18 CET Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > david@boddie.org.uk writes: > > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks > > to some hints from Charles Forsyth. > > Could you post some notes on how you're doing that? This is something > I'd like to take for a spin. I quickly wrote up something that is hopefully useful: https://dboddie.gitlab.io/inferno-diary/2022-01-29.html I'll add more over the weekend. David ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M0c6e3d7df35921958d72097a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 2835 bytes --] The 9front /sys/src/9/zynq port is aiju board's kernel. That could be ported to another zynq board like the little digilent cora z7 or arty z7. Those are just examples, there are many other zynq 7000 boards. Aiju also did a cyclone SoC port for 9front. On Fri, Jan 28, 2022, 4:08 PM Eli Cohen <echoline@gmail.com> wrote: > I started working on a project with an ESP32 board (with a toolchain for > linux) to make a /net/etherESP32 for wifi with 9P right on the little > board. I got as far as realizing how different 802.11 and 802.3 are... > > the unfinished code is at https://github.com/echoline/etherESP32 > > it would be cool to see an aijuboard with accelerated hardware devdraw on > the fpga if that's even possible, or other hardware like that > > On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza <clueelf@tonymendoza.us> wrote: > >> Sorry wrong libstyx repo >> >> https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx >> >> T >> >> On 1/28/2022 at 2:54 PM, "Tony Mendoza" <clueelf@tonymendoza.us> wrote: >> >> A few years back I started trying to build something similar off of the >> STM32F4 line of ARM MCUs. >> >> https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html >> >> Supports ethernet, spi, usb otg, etc. Thought about porting the libstyx >> library from Inferno over to >> the STM32 platform. >> >> https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest >> >> Thin OS layer was provided by FreeRTOS. STM32F4 specific HW was accessed >> using libopencm3 >> >> https://libopencm3.org/ >> >> If interested... >> >> https://github.com/tmendoza/stm32f4-template >> >> Tony >> >> On 1/28/2022 at 4:18 AM, "Lucio De Re" <lucio.dere@gmail.com> wrote: >> >> On 1/28/22, Bakul Shah <bakul@iitbombay.org> wrote: >> > >> > Think of really simple, low power, low cost devices. >> > USB can also provide power. USB+ATtiny85 devel boards >> > cost ~$3 even at Amazon. And FPGA boards can be >> > pretty inexpensive too. If you can find them. >> > >> I've recommended olimex.com in the past. They specialise in Open >> Architecture Hardware. Their prices are very reasonable and product >> range quite broad. >> >> Lucio. >> >> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Me6241517a2c3673d4467fc7a> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M4707ffb9fa69457c676440cc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 5793 bytes --]
[-- Attachment #1: Type: text/plain, Size: 941 bytes --] This is awesome! Thanks so much! I wanted to do something like this for some time. Would love to do my embedded dev for this platform using plan9. T On 1/28/2022 at 8:10 PM, "David Boddie" wrote:On Saturday, 29 January 2022 02:04:18 CET Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > david@boddie.org.uk writes: > > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks > > to some hints from Charles Forsyth. > > Could you post some notes on how you're doing that? This is something > I'd like to take for a spin. I quickly wrote up something that is hopefully useful: https://dboddie.gitlab.io/inferno-diary/2022-01-29.html I'll add more over the weekend. David ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M64e8e7a00932b964f41ab962 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 2235 bytes --]
I've been working on something along those lines for IoT management and networking. Here's my laundry list of architectural and implementation pieces: 1. authentication: (a) tie devices to owner/user (b) authenticate users against third parties (via OIDC/SAML2, etc), (c) let the authenticated user provide the credentials to authenticate and use their devices via a namespace that follows an established convention (e.g. /joe/iot/0/secret). 2. device and capability discovery is a bootstrapping process, starting with a namespace that describes the availability of devices and features (analogous to '#c/drivers') 3. namespace to discover how to present the data from a particular source (e.g. a steam gauge widget would need to understand the namespace exported by a pressure sensor) 4. 9p libraries including fan-in, fan-out capability (i.e. mount, 9pserve) for FreeRTOS, Mbed OS, ThreadX, Zephyr 5. libraries to localize user↔device 9p traffic, while keeping authentication centralized (e.g. how @tailscale works) Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and actuators, until standards and conventions are established. For hardware, targeting things like SAMD21 boards seem more appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic nRF52840 boards are below $10 and include the hardware to establish root-of-trust. On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah <bakul@iitbombay.org> wrote: > > The idea: > - make it very easy to create hardware gadgets by > providing a firmware/hardware building block that > talks 9p on the host interface side & interfaces > with device specific hardware. > > - use a "universal" 9p driver on the host side that > allows access to any such 9p device even from a shell. > > - provide a standard way to find out device capabilities. > > - together they provide a plug-and-play setup. > > Example: connect an LED and a current sensor to this > 9p device, other necessary hardware, add a few config > bits and plug this device kn]]into a host. Now you should > be able to turn on/off the light or sense its state. > > Similarly you should be able to control a stepper motor > servo, cameras, microphones, other actuators, sensors, > IO etc. Eventually you should be able to snap together > enough of these components to build larger assemblies > such as a 3D printer. > > Another example: a "hub" to multiplex such downstream > devices and make them available to a host. > > This will probably have to ride on USB first. A verilog > implementation would be useful in an FPGA! > > Would this be a useful component? If such a thing were > available, what would you want to build with it? > > Do you think 9p is the right protocol for this? > > Ideally > - connect anything to anything > - authenticated connections > - drive the device through a shell script > - no new low level drivers > - self-identifying devices with help and command syntax > - signicantly eases the task of creating new h/w devices. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M79ef31466316e414d50336d2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Apparently Linux includes drivers for tunneling IP over a USB connection (possibly to support mobile phones? not sure...) Making host drivers compatible with these (if not already available) to share an IP stack and creating the equivalent device-side support for the "blocks" would allow 9P to be tunneled not only from these devices but also from other existing solutions in a wider variety of ways, also making it easier to connect those devices to Linux as there are ways to talk 9P from there. That may open up some additional flexibility? On 1/29/22 4:16 AM, Skip Tavakkolian wrote: > I've been working on something along those lines for IoT management > and networking. Here's my laundry list of architectural and > implementation pieces: > > 1. authentication: (a) tie devices to owner/user (b) authenticate > users against third parties (via OIDC/SAML2, etc), (c) let the > authenticated user provide the credentials to authenticate and use > their devices via a namespace that follows an established convention > (e.g. /joe/iot/0/secret). > 2. device and capability discovery is a bootstrapping process, > starting with a namespace that describes the availability of devices > and features (analogous to '#c/drivers') > 3. namespace to discover how to present the data from a particular > source (e.g. a steam gauge widget would need to understand the > namespace exported by a pressure sensor) > 4. 9p libraries including fan-in, fan-out capability (i.e. mount, > 9pserve) for FreeRTOS, Mbed OS, ThreadX, Zephyr > 5. libraries to localize user↔device 9p traffic, while keeping > authentication centralized (e.g. how @tailscale works) > > Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and > actuators, until standards and conventions are established. > > For hardware, targeting things like SAMD21 boards seem more > appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic > nRF52840 boards are below $10 and include the hardware to establish > root-of-trust. > > > On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah <bakul@iitbombay.org> wrote: >> The idea: >> - make it very easy to create hardware gadgets by >> providing a firmware/hardware building block that >> talks 9p on the host interface side & interfaces >> with device specific hardware. >> >> - use a "universal" 9p driver on the host side that >> allows access to any such 9p device even from a shell. >> >> - provide a standard way to find out device capabilities. >> >> - together they provide a plug-and-play setup. >> >> Example: connect an LED and a current sensor to this >> 9p device, other necessary hardware, add a few config >> bits and plug this device kn]]into a host. Now you should >> be able to turn on/off the light or sense its state. >> >> Similarly you should be able to control a stepper motor >> servo, cameras, microphones, other actuators, sensors, >> IO etc. Eventually you should be able to snap together >> enough of these components to build larger assemblies >> such as a 3D printer. >> >> Another example: a "hub" to multiplex such downstream >> devices and make them available to a host. >> >> This will probably have to ride on USB first. A verilog >> implementation would be useful in an FPGA! >> >> Would this be a useful component? If such a thing were >> available, what would you want to build with it? >> >> Do you think 9p is the right protocol for this? >> >> Ideally >> - connect anything to anything >> - authenticated connections >> - drive the device through a shell script >> - no new low level drivers >> - self-identifying devices with help and command syntax >> - signicantly eases the task of creating new h/w devices. > ------------------------------------------ > 9fans: 9fans > Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M79ef31466316e414d50336d2 > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mf859fd621824fda00d5f5c43 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Evidently there are two major standards: CDC, an official USB standard - specifications here: https://www.usb.org/sites/default/files/CDC_EEM10.pdf RNDIS, a proprietary Microsoft protocol that Linux also provides drivers for: https://en.wikipedia.org/wiki/RNDIS The man page for usb/ether on plan9 indicates that CDC support is already there but has not been tested; it may be that a good starting point is in place and getting this tested would provide the required support on the host side of things? On 1/29/22 6:56 AM, Frank D. Engel, Jr. wrote: > Apparently Linux includes drivers for tunneling IP over a USB > connection (possibly to support mobile phones? not sure...) > > Making host drivers compatible with these (if not already available) > to share an IP stack and creating the equivalent device-side support > for the "blocks" would allow 9P to be tunneled not only from these > devices but also from other existing solutions in a wider variety of > ways, also making it easier to connect those devices to Linux as there > are ways to talk 9P from there. > > That may open up some additional flexibility? > > > On 1/29/22 4:16 AM, Skip Tavakkolian wrote: >> I've been working on something along those lines for IoT management >> and networking. Here's my laundry list of architectural and >> implementation pieces: >> >> 1. authentication: (a) tie devices to owner/user (b) authenticate >> users against third parties (via OIDC/SAML2, etc), (c) let the >> authenticated user provide the credentials to authenticate and use >> their devices via a namespace that follows an established convention >> (e.g. /joe/iot/0/secret). >> 2. device and capability discovery is a bootstrapping process, >> starting with a namespace that describes the availability of devices >> and features (analogous to '#c/drivers') >> 3. namespace to discover how to present the data from a particular >> source (e.g. a steam gauge widget would need to understand the >> namespace exported by a pressure sensor) >> 4. 9p libraries including fan-in, fan-out capability (i.e. mount, >> 9pserve) for FreeRTOS, Mbed OS, ThreadX, Zephyr >> 5. libraries to localize user↔device 9p traffic, while keeping >> authentication centralized (e.g. how @tailscale works) >> >> Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and >> actuators, until standards and conventions are established. >> >> For hardware, targeting things like SAMD21 boards seem more >> appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic >> nRF52840 boards are below $10 and include the hardware to establish >> root-of-trust. >> >> >> On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah <bakul@iitbombay.org> wrote: >>> The idea: >>> - make it very easy to create hardware gadgets by >>> providing a firmware/hardware building block that >>> talks 9p on the host interface side & interfaces >>> with device specific hardware. >>> >>> - use a "universal" 9p driver on the host side that >>> allows access to any such 9p device even from a shell. >>> >>> - provide a standard way to find out device capabilities. >>> >>> - together they provide a plug-and-play setup. >>> >>> Example: connect an LED and a current sensor to this >>> 9p device, other necessary hardware, add a few config >>> bits and plug this device kn]]into a host. Now you should >>> be able to turn on/off the light or sense its state. >>> >>> Similarly you should be able to control a stepper motor >>> servo, cameras, microphones, other actuators, sensors, >>> IO etc. Eventually you should be able to snap together >>> enough of these components to build larger assemblies >>> such as a 3D printer. >>> >>> Another example: a "hub" to multiplex such downstream >>> devices and make them available to a host. >>> >>> This will probably have to ride on USB first. A verilog >>> implementation would be useful in an FPGA! >>> >>> Would this be a useful component? If such a thing were >>> available, what would you want to build with it? >>> >>> Do you think 9p is the right protocol for this? >>> >>> Ideally >>> - connect anything to anything >>> - authenticated connections >>> - drive the device through a shell script >>> - no new low level drivers >>> - self-identifying devices with help and command syntax >>> - signicantly eases the task of creating new h/w devices. >> ------------------------------------------ >> 9fans: 9fans >> Permalink: >> https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M79ef31466316e414d50336d2 >> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription >> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M2bfae57976b54c9111775826 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Ok, sorry for the triple-post, but since I can't seem to find that man page or usb/ether on my 9front install, I should probably provide my source: http://man.cat-v.org/plan_9/4/usb On 1/29/22 7:14 AM, Frank D. Engel, Jr. wrote: > Evidently there are two major standards: > > CDC, an official USB standard - specifications here: > https://www.usb.org/sites/default/files/CDC_EEM10.pdf > > RNDIS, a proprietary Microsoft protocol that Linux also provides > drivers for: https://en.wikipedia.org/wiki/RNDIS > > > The man page for usb/ether on plan9 indicates that CDC support is > already there but has not been tested; it may be that a good starting > point is in place and getting this tested would provide the required > support on the host side of things? > > > On 1/29/22 6:56 AM, Frank D. Engel, Jr. wrote: >> Apparently Linux includes drivers for tunneling IP over a USB >> connection (possibly to support mobile phones? not sure...) >> >> Making host drivers compatible with these (if not already available) >> to share an IP stack and creating the equivalent device-side support >> for the "blocks" would allow 9P to be tunneled not only from these >> devices but also from other existing solutions in a wider variety of >> ways, also making it easier to connect those devices to Linux as >> there are ways to talk 9P from there. >> >> That may open up some additional flexibility? >> >> >> On 1/29/22 4:16 AM, Skip Tavakkolian wrote: >>> I've been working on something along those lines for IoT management >>> and networking. Here's my laundry list of architectural and >>> implementation pieces: >>> >>> 1. authentication: (a) tie devices to owner/user (b) authenticate >>> users against third parties (via OIDC/SAML2, etc), (c) let the >>> authenticated user provide the credentials to authenticate and use >>> their devices via a namespace that follows an established convention >>> (e.g. /joe/iot/0/secret). >>> 2. device and capability discovery is a bootstrapping process, >>> starting with a namespace that describes the availability of devices >>> and features (analogous to '#c/drivers') >>> 3. namespace to discover how to present the data from a particular >>> source (e.g. a steam gauge widget would need to understand the >>> namespace exported by a pressure sensor) >>> 4. 9p libraries including fan-in, fan-out capability (i.e. mount, >>> 9pserve) for FreeRTOS, Mbed OS, ThreadX, Zephyr >>> 5. libraries to localize user↔device 9p traffic, while keeping >>> authentication centralized (e.g. how @tailscale works) >>> >>> Initially IoT's would 9p-enable the SPI, I²C, etc. sensors and >>> actuators, until standards and conventions are established. >>> >>> For hardware, targeting things like SAMD21 boards seem more >>> appropriate; they're cheap (e.g. Seeed XIAO). Even things like Nordic >>> nRF52840 boards are below $10 and include the hardware to establish >>> root-of-trust. >>> >>> >>> On Thu, Jan 27, 2022 at 2:58 PM Bakul Shah <bakul@iitbombay.org> wrote: >>>> The idea: >>>> - make it very easy to create hardware gadgets by >>>> providing a firmware/hardware building block that >>>> talks 9p on the host interface side & interfaces >>>> with device specific hardware. >>>> >>>> - use a "universal" 9p driver on the host side that >>>> allows access to any such 9p device even from a shell. >>>> >>>> - provide a standard way to find out device capabilities. >>>> >>>> - together they provide a plug-and-play setup. >>>> >>>> Example: connect an LED and a current sensor to this >>>> 9p device, other necessary hardware, add a few config >>>> bits and plug this device kn]]into a host. Now you should >>>> be able to turn on/off the light or sense its state. >>>> >>>> Similarly you should be able to control a stepper motor >>>> servo, cameras, microphones, other actuators, sensors, >>>> IO etc. Eventually you should be able to snap together >>>> enough of these components to build larger assemblies >>>> such as a 3D printer. >>>> >>>> Another example: a "hub" to multiplex such downstream >>>> devices and make them available to a host. >>>> >>>> This will probably have to ride on USB first. A verilog >>>> implementation would be useful in an FPGA! >>>> >>>> Would this be a useful component? If such a thing were >>>> available, what would you want to build with it? >>>> >>>> Do you think 9p is the right protocol for this? >>>> >>>> Ideally >>>> - connect anything to anything >>>> - authenticated connections >>>> - drive the device through a shell script >>>> - no new low level drivers >>>> - self-identifying devices with help and command syntax >>>> - signicantly eases the task of creating new h/w devices. >>> ------------------------------------------ >>> 9fans: 9fans >>> Permalink: >>> https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M79ef31466316e414d50336d2 >>> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription >>> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M06b50380a603d3037a973a37 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> Ok, sorry for the triple-post, but since I can't seem to find that man > page or usb/ether on my 9front install, I should probably provide my source: /sys/src/cmd/nusb/ether/ -- cinap ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mebc09381f92048e13648c6bb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
I've pushed some code to a git repository: https://gitlab.com/dboddie/bare-metal-stm32f405 I'll write more about it as I tidy it up. David On Saturday, 29 January 2022 03:08:31 CET David Boddie wrote: > On Saturday, 29 January 2022 02:04:18 CET Lyndon Nerenberg (VE7TFX/VE6BBM) > > wrote: > > david@boddie.org.uk writes: > > > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks > > > to some hints from Charles Forsyth. > > > > Could you post some notes on how you're doing that? This is something > > I'd like to take for a spin. > > I quickly wrote up something that is hopefully useful: > > https://dboddie.gitlab.io/inferno-diary/2022-01-29.html > > I'll add more over the weekend. > > David ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M2a9741bb2ab64ebe6d55d2b6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> The 9front /sys/src/9/zynq port is aiju board's kernel. This reminds me to ask ... what did people get up to using their aiju boards for? Sadly, mine has been sitting on the shelf collecting dust for much too long. I did some early fiddling about, mostly to learn the fpga toolchain, but then real life got in the way of playing. When I bought the board I had intended to use it for some SDR receiver applications I was thinking about: AIS, ADS-B, DRM, etc. I really should do something about that. --lyndon ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Taa49c8d083b69cc5-M3bba113188df97d72f1f9820 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
A few thoughts after chewing on this for a day ... I think the major architecture components break down like this: 1) a simple protocol wrapper to enable streaming of 9p over arbitrary transports (e.g. USB, i2c, spi, rs485). 2) an addressing scheme that plugs into dial() and ndb. 3) authentication proxies. 4) device libraries. I think (4) is out of scope for the current discussion, so I won't talk about it further. (1) is the key to the whole thing. We need a consistent way to expose these 9p streams in the kernel in a mount-friendly way. I think the netif/ether kernel framework provides a good starting point, where netif hides (or at least abstracts) the device-specific quirks of the underlying physical medium (e.g. X-Base-T, wifi). In the current case, the netif replacement layer would hide the transport-specific warts of the physical tranport medium (e.g. USB, spi, serial uart). Where it gets interesting is how we address the individual components. E.g. at the "device" layer we need to address specific end-points, such as USB device endpoints, or an i2c chip addresses (for both the i2c driver chip, and the device on its i2c bus we want to talk to). Then above that we should have a way to address the generic 9p stream. Or maybe not -- implementation experience will show if this is required. This naturally leads into (2). (3) gets tricky. Devices not directly connected to a TCP transport can't speak with the auth service. Two ideas come to mind. The upstream "gateway" host could export a namespace that provides just enough to allow the device to chat with the auth service; I haven't thought about how this would work. Another option would be to have the "gateway" provide an auth server relay service that would be part of the 9p streaming encapsulation layer -- basically a 9p bent-pipe proxy to the auth service, listening at a well known "address" within the encapsulation layer. I've been thinking about doing something like this for ages, specifically, to allow me to control a stack of radio transceivers via a collection of controllers wired up to a multidrop RS485 bus. So last night I bit the bullet and ordered up a stack of RS485 interfaces of various shapes and flavours for my collection of Pies, Arduinos, and PCs, with a couple of USB adapters thrown in for good measure :-) When they get here I'll get to work on implementing the RS485 bus layer, and see where it all goes from there. --lyndon ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T18287f976e8461f3-M89dba67665ed6ae12c21e8b4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
A short update on the RS-485 network project ... I ordered up an assortment of RS-485 "hats" and USB serial ports to play with. I also have an Axxon LF1006KB PCIe card that will go into the CPU server as the "gateway" for the 485 network. It should already work with the uartpci driver, but I'll have to extend that to add support for the 485-specific card functions. Fortunately Axxon has been very forthcoming with documentation for the card, so this should be pretty straight forward. I decided to take this week off work so I could free up some cycles to get myself orgainized enough to start on this ;-) I need a week just to dig out from under the mess that my apartment has become during lockdown! Mostly I need to (re-)construct a proper Plan 9 environment to base all of this on, so most of this week is dedicated to building CPU and file servers, etc. But just maybe, by the weekend, I'll have a couple of Plan 9 devices chatting over the RS-485 link. --lyndon ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M6753c1dbc56119369a0cc01a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription