My being relatively new to the FreeBSD forums, presently a former student of a certain for-profit school -- of a program ostensibly teaching about electrical sciences, the program addressing embedded computing not really any further than NI LabVIEW and an old Texas Instruments Stelaris Eval Kit, one DeVry University -- and not being all up-to-date about DocBook on FreeBSD, I thought it might be helpful to present a juxtaposition about each of the NanoBSD and Crochet tools, as both being components available to any manner of an embedded computing systems development toolchain in applications of FreeBSD.
Personally, my interest is in developing applications off the BeagleBone Black platform. I understand that there may seem to be a certain competitive quality about embedded computing systems designs. Personally, I've reviewed some information about the Gumsix, Raspberry Pi, BeagleBone Black, and Cubieboard/Cubietruck platforms. In that each may be presented as, in some regards, a commercial product, I understand that there are specific distributors available that provide resale services about each respective platform. Outside of existing microprocessor designs, of course there are the FPGA platforms furthermore -- the Mojo v3 for instance, and the Papilio platform, both applying Xilinx Sparan FPGAs, and both applying the Xilinx ISE WebPack for FPGA programming.
In a manner of a sidebar about Intellectual Property in design channels: Personally, I've proposed to develop primarily a toolchains-oriented view, to begin with, but not to overlook any concerns such as with regards to Intellectual Property (IP) management -- as specifically, may be of a concern as with regards to individual design documents, and separately as with regards to IP in FPGA design channels. I understand that IP may not be a widely popular topic. Though I know that there are ample criticisms about concepts of IP in electronics design, I consider that there is a certain quality of nonrepudiation -- more broadly, a quality of authenticity -- attending typically with an IP "facet" in systems design. For commercial applications, I'm certain I would be unable to overlook an IP facet in systems design. Perhaps it may seem, in ways, mystifying if IP is not being addressed directly as a concept in systems design. Perhaps it may seem to be less of a concern, outside of an FPGA design channel. With the source code of the Apollo Guidance Computer being available online, I believe it may represent a much broader topic. I do not propose to try to address the topic singularly in this article, though I think it deserves a fair amount of mindful consideration. Personally, I'm glad that the FreeBSD project does not seem expressly antagonistic about Intellectual Property rights. I think that the topic may represent a particularly challenging topic to address, and address at detail, without disrespecting anyone's right to -- in a sense -- to complain about IP regulations, and to complain as without actually presenting any real alternatives to an IP-controlled design channel.
Beyond applications about existing microprocessor designs, if there may be applications for FreeBSD in an FPGA design channel -- for instance, as could be developed in extending of the Open Cores WishBone bus model and perhaps also the OpenSparc system-on-chip (SoC) design -- I'm principally uncertain of how or whether the broader design community may endeavor to accept that there is an IP facet in commercial FPGAs systems design. Perhaps it may be easier to start with FreeBSD than with some other free/open source operating systems, if in developing such a project, such as towards developing an application of FreeBSD on an FPGA platform.
In focusing immediately about an application of an existing microprocessor architecture -- for instance, the TI AM35X "Sitara" microcontroller design, as applied in the BeagleBone Black platform -- certainly even a single existing microcontroller may seem to present a lot of complexity for applications. Observing that the Sitara has two PRU-ICSS modules available, on the SoC, that each is capable of performing as a device on an I2C network, and that FreeBSD implements an I2C daemon, of course there is the question remaining: Not only of how to install FreeBSD to a BeagleBone Black (BBB), but furthermore, how to develop with this platform?
Personally, I'd encountered some difficulty with regards to an "Install from SD card" option for FreeBSD specifically on BBB. Proceeding from there, perhaps it can seem distinctly mystifying, as a process, from an event A of "Download source code" to an event B of "FreeBSD booted on BBB." Not to propose as if there was only one available channel for proceeding from A to B, thus, I notice that there are two distinct tools available, for applications in embedded computing on a FreeBSD architecture: NanoBSD and Crochet. Beside a prospective FPGA design feature of a computer systems toolchain, perhaps either or both of the NanoBSD and Crochet tools could be applied -- such as for building and installing a FreeBSD root filesystem image -- once the respective FPGA board would be programmed for its respective microcontroller, whether for academic study, debugging and development, or production applications.
Before endeavoring to compare the NanoBSD and Crochet tools in any manner of a perspective as with regards to source code components, I wonder if the two tools will be developed forever independently of each and the other? If a logical model could be developed about each, perhaps it might serve towards developing a compatibility interface about either and both?
Personally, I might be biased about Crochet, considering that Crochet supports development with a single board computing platform that I have one of, on my desk, the BeagleBone/Stellaris platform namely.
Considering the relatively straightforward source tree of each of the NanoBSD and Crochet tools, I'm certain that it may seem fairly trivial to develop any number of graphical tools for each and both, as towards assisting in a manner of development channel. I wonder if it may be possible to develop any kind of a design convergence of the NanoBSD and Crochet tools?
In a short juxtaposition, and to stay true to the title of this -- regrettably -- this markedly rambling article, I notice that the NanoBSD tools include something about a DHCPD service component. May it be an accurate estimate that the NanoBSD DHCP facet may pertain to a PXE/Netboot boot process? Of course, I've read a suggestion that PXE/Netboot may be ideal for embedded systems development, as it does not require much of physical media swapping for installing a new system image to a computing machine.
So far as for ports building, of course both of NanoBSD and Crochet could be applied together with Poudriere, with a specific machine configuration for each -- moreover, as towards an effect of a distinct make.conf for each board.
With regards to building a kernel and base system, moreover for automating the build, of course there's FreeBSD's pmake, orthogonal to ezjail.
There being, certainly, a significant number of components to any single logical model for embedded computing systems development, of course a UML model might not itself write the shell scripts to "Make it go". I wonder if UML could seem "OK" in this forum, though?
Personally, my interest is in developing applications off the BeagleBone Black platform. I understand that there may seem to be a certain competitive quality about embedded computing systems designs. Personally, I've reviewed some information about the Gumsix, Raspberry Pi, BeagleBone Black, and Cubieboard/Cubietruck platforms. In that each may be presented as, in some regards, a commercial product, I understand that there are specific distributors available that provide resale services about each respective platform. Outside of existing microprocessor designs, of course there are the FPGA platforms furthermore -- the Mojo v3 for instance, and the Papilio platform, both applying Xilinx Sparan FPGAs, and both applying the Xilinx ISE WebPack for FPGA programming.
In a manner of a sidebar about Intellectual Property in design channels: Personally, I've proposed to develop primarily a toolchains-oriented view, to begin with, but not to overlook any concerns such as with regards to Intellectual Property (IP) management -- as specifically, may be of a concern as with regards to individual design documents, and separately as with regards to IP in FPGA design channels. I understand that IP may not be a widely popular topic. Though I know that there are ample criticisms about concepts of IP in electronics design, I consider that there is a certain quality of nonrepudiation -- more broadly, a quality of authenticity -- attending typically with an IP "facet" in systems design. For commercial applications, I'm certain I would be unable to overlook an IP facet in systems design. Perhaps it may seem, in ways, mystifying if IP is not being addressed directly as a concept in systems design. Perhaps it may seem to be less of a concern, outside of an FPGA design channel. With the source code of the Apollo Guidance Computer being available online, I believe it may represent a much broader topic. I do not propose to try to address the topic singularly in this article, though I think it deserves a fair amount of mindful consideration. Personally, I'm glad that the FreeBSD project does not seem expressly antagonistic about Intellectual Property rights. I think that the topic may represent a particularly challenging topic to address, and address at detail, without disrespecting anyone's right to -- in a sense -- to complain about IP regulations, and to complain as without actually presenting any real alternatives to an IP-controlled design channel.
Beyond applications about existing microprocessor designs, if there may be applications for FreeBSD in an FPGA design channel -- for instance, as could be developed in extending of the Open Cores WishBone bus model and perhaps also the OpenSparc system-on-chip (SoC) design -- I'm principally uncertain of how or whether the broader design community may endeavor to accept that there is an IP facet in commercial FPGAs systems design. Perhaps it may be easier to start with FreeBSD than with some other free/open source operating systems, if in developing such a project, such as towards developing an application of FreeBSD on an FPGA platform.
In focusing immediately about an application of an existing microprocessor architecture -- for instance, the TI AM35X "Sitara" microcontroller design, as applied in the BeagleBone Black platform -- certainly even a single existing microcontroller may seem to present a lot of complexity for applications. Observing that the Sitara has two PRU-ICSS modules available, on the SoC, that each is capable of performing as a device on an I2C network, and that FreeBSD implements an I2C daemon, of course there is the question remaining: Not only of how to install FreeBSD to a BeagleBone Black (BBB), but furthermore, how to develop with this platform?
Personally, I'd encountered some difficulty with regards to an "Install from SD card" option for FreeBSD specifically on BBB. Proceeding from there, perhaps it can seem distinctly mystifying, as a process, from an event A of "Download source code" to an event B of "FreeBSD booted on BBB." Not to propose as if there was only one available channel for proceeding from A to B, thus, I notice that there are two distinct tools available, for applications in embedded computing on a FreeBSD architecture: NanoBSD and Crochet. Beside a prospective FPGA design feature of a computer systems toolchain, perhaps either or both of the NanoBSD and Crochet tools could be applied -- such as for building and installing a FreeBSD root filesystem image -- once the respective FPGA board would be programmed for its respective microcontroller, whether for academic study, debugging and development, or production applications.
Before endeavoring to compare the NanoBSD and Crochet tools in any manner of a perspective as with regards to source code components, I wonder if the two tools will be developed forever independently of each and the other? If a logical model could be developed about each, perhaps it might serve towards developing a compatibility interface about either and both?
Personally, I might be biased about Crochet, considering that Crochet supports development with a single board computing platform that I have one of, on my desk, the BeagleBone/Stellaris platform namely.
Considering the relatively straightforward source tree of each of the NanoBSD and Crochet tools, I'm certain that it may seem fairly trivial to develop any number of graphical tools for each and both, as towards assisting in a manner of development channel. I wonder if it may be possible to develop any kind of a design convergence of the NanoBSD and Crochet tools?
In a short juxtaposition, and to stay true to the title of this -- regrettably -- this markedly rambling article, I notice that the NanoBSD tools include something about a DHCPD service component. May it be an accurate estimate that the NanoBSD DHCP facet may pertain to a PXE/Netboot boot process? Of course, I've read a suggestion that PXE/Netboot may be ideal for embedded systems development, as it does not require much of physical media swapping for installing a new system image to a computing machine.
So far as for ports building, of course both of NanoBSD and Crochet could be applied together with Poudriere, with a specific machine configuration for each -- moreover, as towards an effect of a distinct make.conf for each board.
With regards to building a kernel and base system, moreover for automating the build, of course there's FreeBSD's pmake, orthogonal to ezjail.
There being, certainly, a significant number of components to any single logical model for embedded computing systems development, of course a UML model might not itself write the shell scripts to "Make it go". I wonder if UML could seem "OK" in this forum, though?