Robert, On Wed, Jul 29, 2020 at 11:35 AM Robert Faron <robe...@cmslaser.com> wrote: > > I am at a bit of a loss, I'll start by saying I am not a programmer by trade > though I have written code for most of my life. My background is in IT, > mainly networking. That being said I have written code in many languages and > find it fairly easy to pic up new ones as it's typically just changes in > syntax but logic is logic. Currently I am in charge of the code base for our > controller which runs a mixture of basic and assembly for the low level > stuff. My goal with Nuttx is to have a RTOS to run our control software > which looks like it will have to be rewritten back into C or even C++. We > have created a new PCIe board that replaces what we are currently using 5 > pc/104 cards. Writing the driver for our PCIe card won't be too hard as I > have written drivers for my previous cards before. > > So At this point I have cloned the git repo and selected the PCI branch, > installed the build tools, configured the system as qemu-intel64:nsh and > successfully make nuttx.bin and nuttx..elf . At this point I am lost. The > document I was reading then talks about loading to an arm device, and I can't > find any information on setting up an AMD64 build on the actual hardware. So > the first step at this point that I don't understand is how to get the system > to boot using the complied nuttx.bin or .elf. >
See the section here on creating a bootable disk. You will need to use GRUB or another bootloader to load the elf file. https://github.com/apache/incubator-nuttx/blob/master/boards/x86_64/intel64/qemu-intel64/README.txt > Once I an get the system to boot I will need to be able to run a compiled > program. I assume I will have to rewrite my little linux test program using > nuttx. At it's simplest the test program can be hard programed to the > correct bar address given by uefi and since it is on it's own but, no other > devices are on bus 1, it should continue to be assigned the same bar address. > This test program will really be as simple as turn on isolated bit, sleep, > turn off sit, sleep again, repeat. This will allow me to test for jitter, in > a true RTOS the outputted square wave will remain consistently the same. If > the OS interrupts the process jitter will appear and can be measured on an > oscilloscope. > > Once that test is complete and it passes I can help get the PCIe sections > working and tested along with helping in other ways. I know the learning > curve will be steep but I'm a pretty good climber. I would recommend using I would also recommend working off of my branch. There is stuff in the current pci branch that will need to go away especially around MSI and MSI-X. If you are ok using the legacy interrupt for now it should be ok. There is an example here I did for the QEMU PCI Edu device that implements interrupts, mmio, and dma. https://github.com/btashton/incubator-nuttx/blob/pci-btashton/drivers/virt/qemu_edu.c I can try to rebase the branch up to master this evening. --Brennan
