search

machinekit / mksocfpga

Hostmot2 FPGA code for SoC/FPGA platforms from Altera and Xilinx
30 stars 40 forks source link

PLEASE STOP adding one-off customizations #25

Closed cdsteinkuehler closed 8 years ago

cdsteinkuehler commented 8 years ago

Please stop changing the hostmot2.vhd file to include the (PIN file of your personal preference of the day). This breaks ALL other configurations each time it's changed, and is not the way the hostmot2 instance should be configured.

There should be only one default PIN_ file sourced directly in the hostmot2.vhd file, and it should generally NEVER change. Instead, PIN file(s) should be sourced one level above, and the appropriate pin descriptor from the desired PIN package should be mapped to the ThePinDesc generic, the way it's done in the hostmot2 source. Actually, IMHO, there should NOT be a default ThePinDesc (so no pin file sourced in hostmot2.vhd), because if you don't have a specific configuration you're targeting, you don't have a proper hostom2 project. This would mandate providing a valid ThePinDesc generic value in the design source code.

NOTE: This may require an additional layer of VHDL 'shim' if the top-level design is in verilog or system-verilog (see https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE0_Nano_SoC_DB25/hostmot2_cfg.vhd for an example).

the-snowwhite commented 8 years ago

OK The change you mention was the only one I was not able to figure out how to implement in the de0_nano_ghrd uio-irq update.

I'll take a look and see If I can duplicate that part of your setup suggestion back into the ghrd config.

cdsteinkuehler commented 8 years ago

On 5/21/2016 5:32 AM, Michael Brown wrote:

OK The change you mention was the only one I was not able to figure out how to implement in the de0_nano_ghrd uio-irq update.

I'll take a look and see If I can duplicate that part of your setup suggestion back into the ghrd config.

There are ways to pass VHDL generics from Verilog to VHDL, but it's cumbersome and vendor specific. I highly recommend a configuration "wrapper" written in VHDL (the file I linked to) which can then use the desired package for configuring the specific hostmot2 instance.

Then it's a small step to have the build scripts adjust the PIN package used prior to building so we can support multiple configurations in the same project directory (a partial solution to issue #9).

Charles Steinkuehler charles@steinkuehler.net

the-snowwhite commented 8 years ago

I'm looking into a solution that also makes these needed parameters available in the
top .sv file

parameter IOPorts       = 4;            // Number of external ports (DE0-Nano_DB25 can have 2 on each 40-pin expansion header)
parameter IOWidth       = 68;           // Number of total I/O pins = IOPorts * PortWidth
parameter PortWidth     = 17;           // Number of I/O pins per port: 17 per DB25
parameter LIOWidth      = 6;            // Number of local I/Os (used for on-board serial-port on Mesanet cards)
parameter LEDCount      = 4;            // Number of LEDs
parameter BusWidth      = 32;
parameter AddrWidth     = 16;
cdsteinkuehler commented 8 years ago

On 5/21/2016 5:44 PM, Michael Brown wrote:

I'm looking into a solution that also makes these needed parameters available in the top .sv file

I agree this is a great idea. There are likely a few more items that need to be included as well (from the gigantic per-board case statement in the existing drivers) . See the recent comments on issue

903:

https://github.com/machinekit/machinekit/issues/903

Charles Steinkuehler charles@steinkuehler.net

mhaberler commented 8 years ago

it's all fine to wire this stuff into the FPGA image

the issue with hm2_register() is - those params are needed before hm2_register() is called

so this boils down to - turn around the startup ordering of the hostmot2: load the FPGA before doing the hm2_register(), as I suggested above as one solution

the point I am lukewarm about: a matching dts is readable. A FPGA image is not (ok, you can load it and look at the log)

dkhughes commented 8 years ago

Are the parameters in the case statement needed before we are communicating with the FPGA? They are mostly friendly names for the gpio that are specified by the PIN file, and a count of the number of LEDs. I see that the current driver requires them early, but I think that is a cumbersome requirement that we can refactor out of the driver. I will make an issue to look at this closer.

As for this issue, the hostmot2 file and it's wrapper on the Xilinx side are autogenerated based on the config, but I hate that. The only reason for this is because the Vivado IP manager cannot handle a generic declaration of a custom data type (PinDesc, BoardName, etc.) at the top level. If that worked, the Xilinx side would be totally configurable without needing to touch anything, but oh well. I've been trying to think of a workaround, but family is visiting the new baby this weekend so I don't have a ton of time. Vivado does do out of context building and its throwing a wrench into the one .vhdl customization file per board plan. The problem is the IP packager must know the path of the vhdl files required to compile, which is specified in a component.xml file. I'm experimenting with just having a missing file (ie. no path or file with the vhdl package), that get's added by the specific project later. Now that the package is on the path at final compile time, I think it will compile even though the earlier IP build would have failed. This VHDL file eliminates the autogenerated customized hostmot2.vhd files, and makes a new port very straightforward: 1) Create your project 2) Update your block diagram to add or remove features the board supports (UART, etc.) 3) Write the custom board vhd file which describes the PINS and your config rom (board name, header names, etc). 4) Specify the physical pin constraints 5) ? 6) Profit!

No messy editing of the main IP source body which should really be reserved for functionality that is not platform / vendor specific. Trouble is, I don't think the block diagram wrapper will succeed because the IP block is "broken".

the-snowwhite commented 8 years ago

I am going to have to look into that Vivado thingie soon, I'm not sure of what this new proposal can do there, however I'm very proud to present this PR: https://github.com/machinekit/mksocfpga/issues/34

the-snowwhite commented 8 years ago

I started from @cdsteinkuehler 's this:

https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE0_Nano_SoC_DB25/hostmot2_cfg.vhd

And then added a sv parameter package.

the-snowwhite commented 8 years ago

@mhaberler

it's all fine to wire this stuff into the FPGA image

the issue with hm2_register() is - those params are needed before hm2_register() is called

I have noticed that there is vacont memory in the hostmot2 address space below address 0x0100.

This is 1 byte of 32 bit address space which translates to exactly 1 KByte of freely avaiable "ram / rom". This data can be populated with any needed data put into the .sv config package, the pin file and or the hostmot2_cpg file or some custom needed data.

The very first steps the kernel 4.1+ hm2_soc_xx driver makes is to inject the .dtbo file which then loads the driver and then configures the fpga (fully or partially).

So the .dts --> dtb0 file only needs to contain all thats nessasary for being able to do initial mmaping of the just loaded driver device file from the freshly configured fpga.

Then we will have 1 KByte of our own custom ram/rom map available before having to do hm2_register ()..?

mhaberler commented 8 years ago

the chicken-and-egg problem is this:

so adding config stuff to the FPGA image does not solve that problem

changing the loading order in hm2_soc_ol - first dtbo load, then hm2_register solves that, and only then values from the FPGA image could become useful

actually the firmware loaded before hm2_register() seemed to be the standard scenario and the delayed firmware load I cooked up now comes back to bite

dkhughes commented 8 years ago

Right, but look at the values being passed in through register... We must have the llio read/write functions, and the fpga program/verify hooks. The num_ioport_connectors, pins_per_connector, connector_names, fpga_part_number, num_leds, are all firmware descriptors that are not needed until later in the register phase. We have a mix of driver hooks, and device specific firmware description hooks. Keep the driver hooks, they are required, move the firmware description hooks to the hostmot2 driver itself when it populates the module descriptors. Win win, right?

mhaberler commented 8 years ago

@dkhughes we could do that but it would require postponing these checks until after firmware loaded and the values can be filled in from the firmware

probably to around here

should this 'fill-in' be another downcall into the llio part (hm2_soc_ol)? I guess that be image-specific so we need some signature to tell if there is a param section to read from

dkhughes commented 8 years ago

I don't think we need a downcall, since those parameters would be generic regardless of interface (ethernet, pcie, uio, etc). We will need to check the idrom version, it's currently 3, and make sure we only query for the parameters from a version 4 or greater rom. Something like:

if(configrom_version > 3)
     read parameters from fpga...
else
     old style - verify the parameters are already set or error

continue with parameters filled out in struct...

in hostmot2.

mhaberler commented 8 years ago

ah ok, I see now how it should work, wunderbar!

the-snowwhite commented 8 years ago

Hmpf

The leftovers from the rev1 3.10 kernel sd-image building overcooking has still left some confusion I really would like to finally clear out:

I really really think you are overlooking something very crucial about the difference of the v3.10 kernel and the 4.1 kernel with the AUTO fpga ConFigure AUTO driver load feature.

The hostmot2 driver (in kernel v4.1+) should NOT in any way load any firmware directly.

This is done by loading the .dtbo file and handled by the kernel automaticially.. (Period).

cat "hm2_my_dts-compiled.dtbo" > /config/devicetree-overlay/uio0/dtbo ..

This is what loads the uio0 device AND configures the fpga, built into the 4.1+ kernel functionality.

Programming the fpga via the hm2_soc_xx Driver was NEVER In the Original DEAL.

Rev1 3.10 kernel u-boot configure fpga.

Rev 4.1+ kernel (with fpga manager framework) Device tree fragment --> load driver + program fpga.

The mksocfpga project has never been intended to program the fpga via any machinekit or mesa related method so Please get out of this CONFUSION, and remove all kinds of direct fpga configuring via .rbf bitfiles totally from this hm2_soc_xx driver concept.

Loading the compiled device tree fragment WILL load the correct driver AND configure the fpga.

So this is the very first step any mksocfpga hm2_xxxx driver has to do in the very first lines of code.....

Am I making myself clear ?

dkhughes commented 8 years ago

Please, stop rushing to the conclusion that we are all completely confused about the firmware / driver relationship. All of us are working together to make this thing better, and maintainable in the future. I'm going to let the punitive tone go as a language barrier thing and try to understand what your point is here. Also, let's assume I understand how the driver I wrote works...

The issue at hand that we are discussing has nothing to do with how a bitfile gets into an FPGA - it is all about how the HAL layer is populated with pins such as IO and leds. Again, I don't care how the FPGA got programmed, I still need this descriptive info to pull out what the hal pins should be called so you get the handy names like hm2_board.0.P3.gpio0 or whatever it ends up being populated to. At the moment, for older designs, that info is coming from a really ugly case switch statement in the llio drivers. That means we manually have to edit the driver for every bitfile type, which is exponentially increasing as we add more SoMs and carriers to the project. Instead, what the proposal above is about is pulling those specific firmware descriptors from the fpga itself after it has been loaded. See the difference? FPGA bitfile is already running, why don't we ask it how we should populate the HAL structure? We already ask it about stepgens, dplls, timers, etc. why not header names and led counts?

P.S. Why is it bad to have the driver load the fpga bitfile? I think it is a great benefit to be able to have the hal file specify an overlay rather than require a separate script or artifact do it before the config can take over. After all, that's the place that knows what hardware it wants. I don't see us being limited to one hardware config per board either - all nice things to be able to choose from in a hal file.

the-snowwhite commented 8 years ago

@dkhughes I think we agree what I'm aiming to shoot down is: @mhaberler

the chicken-and-egg problem is this: hm2_soc_ol driver calls hm2_register() hm2_register() calls the firmware load routine which inserts the dtbo which inserts the firmware hm2_register() needs some values to succed

Which I think is overcomplicating the discussion:

THis line is totally wrong IMHO

hm2_register() calls the firmware load routine which inserts the dtbo which inserts the firmware

No

OK What has been bugging me is that I had worked out that issue however the documentation and commit somehow got lost from my initial 4.1-ltsi-rt machinekit branch please look at this very important addition to the very first lines of code to run in the mksocfpga hm2_xxx driver:

int rtapi_app_main(void) {
    int r = 0;
    int rc;

    LL_PRINT("loading Mesa AnyIO HostMot2 socfpga driver version " HM2_SOCFPGA_VERSION "\n");

//  if (!(r = is_module_loaded("hm2reg_ui"))) {
//      LL_ERR("hm2reg_uio not loaded!");
//      return r;
//  }
    char devname[100];
    rtapi_snprintf(devname, sizeof(devname),"/config/device-tree/overlays/%s", fpga_hm2_drv);

    if(access( devname, R_OK ) == -1 ) {
        LL_PRINT("device tree overlay node: %s not found ...  will create it\n", devname);
            rc = run_shell("/bin/mkdir /config/device-tree/overlays/%s", fpga_hm2_drv);

            if (rc) {
                LL_ERR("run_shell(/bin/mkdir /config/device-tree/overlays/%s) failed: %s\n", fpga_hm2_drv, strerror(errno));
                return -errno;
        }
    }

    comp_id = hal_init(HM2_LLIO_NAME);
    if (comp_id < 0) return comp_id;

    r = hm2_soc_register(&board[0], uio_dev, fpga_hm2_drv);
    if (r != 0) {
        LL_ERR("error registering UIO driver\n");
        hal_exit(comp_id);
        return r;
    }

    if (failed_errno) {
    // at least one card registration failed
    hal_exit(comp_id);
    r = hm2_soc_munmap(&board[0]);
    return r;
    }

    if (num_boards == 0) {
    // no cards were detected
    LL_PRINT("error - no supported cards detected\n");
    hal_exit(comp_id);
    r = hm2_soc_munmap(&board[0]);
    return r;
    }
    hal_ready(comp_id);
    return 0;
}

Hmm actually a lot of the thoughts from that branch got lost in the furry ,,, dts ,,, dtbo ,,, partial ,, reconfiguration. ... fpga manager ,,, dts overlay framework

the-snowwhite commented 8 years ago

@dkhughes

The issue at hand that we are discussing has nothing to do with how a bitfile gets into an FPGA - it is all about how the HAL layer is populated with pins such as IO and leds. Again, I don't care how the FPGA got programmed,

I am very worried that continuation of these thoughts will serve as a major roadblocking for evolving towards the greater vision behind my reasons for manifesting this project in the first place.

If you look towards in the very near future being able to in the first step only having to recompile and swap in out that exact hm2 config you have defined in the PIN file + any other config options suggested in my latest PR.

And you do that by using a partial device tree fragment containing that exact partial chunk of needed fpga hardware + all the needed config info in the bundle, you then have no need at all to do any kind of "backwards" probing from the fpga rom, you would be much more inclined to inject something the other way from your dtbo .deb firmware package into the hostmot2 core.

Next step will be being able to route the "fixed" hm2 cores in / out signals through controlling a mux from the hal.

Further development steps will be enabling instantiation (realtime load and unload) of fpga cores directly from the hal. This is the natural evolution path.

I just have a strong opinion towards placing roadblocks that just will make this evolution drag out and take much longer time than needed...

In the future:

the HAL layer is populated with pins such as IO and leds

Via loading dts fragments programming / configuring the fpga and mesa rom / features as needed on the fly.

I may be talking about mesa "ram" revision v5 versus m,esa "rom" v3.

:-)

mhaberler commented 8 years ago

@the-snowwhite ok let's talk about what is in mk/mk because I tend to get lost in other information bits and pieces floating around:

how is this conceptually different from your 

        rc = run_shell("/bin/mkdir /config/device-tree/overlays/%s", fpga_hm2_drv);

above except for the startup phase where it is called (other than @dkhughes code being super robust about closing race conditions)

then, further above we're discussing what to do in which phase so we're not far apart, the result is going to be the same

but here is another angle: every single hm2 lowlevel driver which might support firmware loading, and all the configs use the config="firmware=<fw> other args" method. We should strive for keeping that even if it incurs some minimal effort, and I think @dkhughes 's idea is minimal in impact.

If 'firmware=foo" refers to a dtbo called foo, or a firmware blob called foo is irrelevant from a user perspective as long as the right thing happens, which does IMO.

AFAICT your proposal would change this only for the hm2_soc_ol driver to move the firmware argument to a separate driver command line argument. That needs to be documented as an exception only for this driver. Why - if we can achieve compatibility with minor effort?

I do not exclude I am overlooking something but frankly I cannot currently see it?

dkhughes commented 8 years ago

@mhaberler I totally agree. Since the config=firmware=<fw> mechanism is already in place it seemed like the easiest way to get the firmware of the fpga into the driver - and it's comfortable and familiar for people already using mesa hardware.

@the-snowwhite I can appreciate your grand plan for the project in the future, but here is the trouble. We have a working, reasonably robust framework right now. One that everyone already understands. Not adding maintainability and polish to it to make it fit with all the existing hardware before a fundamental shift in the api isn't an option. That's what branches are all about - consider this one testing/stable and make the new code an experimental branch. Wouldn't your partial config scheme require the HAL drivers to apply the overlays based on config anyhow? Isn't this kind of a baby step in that direction? If we can apply one overlay through the HAL, we can apply many....

ASIDE: There are roadblocks to your partial configuration scheme that I can see:

1) Device incompatibility - how you generate the bitfiles for each fpga device (not just vendor) can be different. Are the bitfiles for a cyclone v soc the same as Arria 5? Artix vs Kintex? Instead of the bitfile per board config, now you have a bitfile per module per fpga device - That's exponentially more build artifacts to keep track of. I think it can be done, but a lot of work will have to go in to management and deployment.

2) There are a limited number of luts in the fpgas. Partial configuration requires an entire region to be able to reconfigure without overwriting other partial designs. I think in altera devices that's based on which bridges are active. Are there enough regions/bridges in a device to enable a reasonably sized HAL design in the fpga? Or will the bitfile blobs be logical combinations of HAL components prepackaged?

3) Bang for my development time buck. What do we get for all of this rewrite effort that can't be provided by the current framework, but with the addition of features? I could add hardware PID, hardware based motion planning, powerlink, etc. etc. to the current design and see big gains in performance on these (relatively) processor limited devices.

There are more, but I feel they belong else where in a discussion more suited to rerolling the framework. I only mention them here because I do disagree with what you consider the grand scheme of the project in the future. I like the ability of the current framework to support legacy firmware devices, which aren't really legacy since they are still for sale. I like the simplicity of a single bitfile that is easily run on a machine in a known working state without the question of partial config missing timing closure for some esoteric reason. Plus, I like Peter Wallace's VHDL. It's a really well thought out design that is easy to follow and pretty solid in operation.

mhaberler commented 8 years ago

Well, there's nothing to be said against @the-snowwhite working this out in a test branch but I wouldnt rush this into master until it's proven, the upside shows and the not-so-phun gory details are sorted - build, CI, regression tests, docs etc (the mythical machinekit volunteer force routinely delivers a no-show on these aspects, btw).

In the minimum code in master must remain unbroken.

having thought about this partial reconfig stuff, I think the way to do this from a HAL perspective is to make the hm2_soc_ol driver an instantiable component. That is an addition @ArcEye and me did a while ago - not terribly well documented but this shows the idea

A common ground could be this:

mhaberler commented 8 years ago

re firmware options

why dont we create firmwares which varies only in I/O configuration (pins, connectors, type of/how many Mesanet tentacle cards) but other than that fill up the FPGA cell space to the gills? I understand there's lots of room left - what a waste;) and build time really dont matter too much

there might be shades - like stepper, servo, triphase/bldc but let's apply 80/20 - I think that would cover the majority of usage scenarios with the minimum logistics efforts

those with really exotic requirements still have the option of 'git pull', edit, and 'docker pull' to do it themselves - no point in saving the whales at high cost and at this point

cdsteinkuehler commented 8 years ago

On 5/24/2016 5:35 PM, Michael Haberler wrote:

re firmware options

why dont we create firmwares which varies only in I/O configuration (pins, connectors, type of/how many Mesanet tentacle cards) but other than that fill up the FPGA cell space to the gills? I understand there's lots of room left - what a waste;) and build time really dont matter too much

The FPGA is already 66% full on my 4x 7i76 config, so there isn't a vast amount of space left, at least in the smaller FPGAs. Also, to make use of anything like this, we would need something like the pinmux layer used on the BeagleBone and the corresponding complexity of setting it up, limitations of which pins could do which functions, etc.

I think replicating the existing Mesa setup with PIN* files used to configure the hardware is low-hanging fruit and causes the least confusion. Once that's working we can address any issues and improve things if needed. I honestly don't expect there to be much hassle involved in maintaining the PIN* files once the initial set of configurations are determined.

Charles Steinkuehler charles@steinkuehler.net

the-snowwhite commented 8 years ago

?? @cdsteinkuehler

please comment on this:

https://github.com/machinekit/mksocfpga/issues/18

the-snowwhite commented 8 years ago

@mhaberler

@the-snowwhite ok let's talk about what is in mk/mk because I tend to get lost in other information bits and pieces floating around:

how is this conceptually different from your

    rc = run_shell("/bin/mkdir /config/device-tree/overlays/%s", fpga_hm2_drv);

THe Really important difference is that I added a load dtbo file as the first hm2_register callback function. To use Instead of the load firmware (.rbf) bitfile.

For this to work it requires the: /config/device-tree/overlays/uiox folder to have been created first.

THen applying @dkhughes robust timeout load function instead of the very primitive delay counter loop I came up with for testing.

the-snowwhite commented 8 years ago

@dkhughes

ASIDE: There are roadblocks to your partial configuration scheme that I can see:

There are various technical advances to the reconfig scheme that only so far have been hinted at publicially, and not easiely understood as we are talking about new unknown concepts.

I have created a new Repo containing a detached copy ot the mksocrepo for developing what I have branded the working name Hostmot3: (I will of course not accept any kind of limitation discussion there as this kills the ability to manisfest something new ... :-) )

https://github.com/the-snowwhite/mksocfpga_hm3

the-snowwhite commented 8 years ago

@cdsteinkuehler @dkhughes Lastly please look into and comment this PR for the hostmot2, Suggesting slight changes to make it very easy to generate batch compilations(in Quartus only ?):

I'm trigger happy with New all in 1 file multi batch compile style: #34 #35

cdsteinkuehler commented 8 years ago

On 5/25/2016 6:10 AM, Michael Brown wrote:

?? @cdsteinkuehler https://github.com/cdsteinkuehler

please comment on this:

18 https://github.com/machinekit/mksocfpga/issues/18

Yes, adding something like the Linux pinmux functionality to the hostmot2 code is possible, but it holds very little interest for me at the moment.

My priorities are to get the existing Mesa VHDL code integrated into an SoC+FPGA build chain with as little modification as possible, while making it as easy as possible to craft a new configuration and have it "trickle down" into firmware packages, uSD images, etc. in the hopes of making something usable enough we can gain real-world users.

Once this foundation is in place, I'd be happy to see the internal tri-state buses removed and switched to separate input and output buses (for both the I/O pins and the register bus).

Once THAT is completed, it makes sense to start talking about adding a pinmux layer and all the software and run-time configuration hassle that comes along with it.

...but that's my personal view and goal. Everyone should feel free to work on whatever they want, although it's generally considered bad form to break already working code in the process (which is why I initially created this issue). :)

Charles Steinkuehler charles@steinkuehler.net

dkhughes commented 8 years ago

My priorities are to get the existing Mesa VHDL code integrated into an SoC+FPGA build chain with as little modification as possible, while making it as easy as possible to craft a new configuration and have it "trickle down" into firmware packages, uSD images, etc. in the hopes of making something usable enough we can gain real-world users.

Totally agree.

Once this foundation is in place, I'd be happy to see the internal tri-state buses removed and switched to separate input and output buses (for both the I/O pins and the register bus).

Can the socfpga (altera) side support direct axi bus components easily from qsys? The input output data buses are already split, but the address bus is shared which didn't allow me to do simultaneous read/write in the axi wrapper on the zynq. You can see the state machine at https://github.com/machinekit/mksocfpga/blob/master/HW/zynq-ip/hm2_axilite/src/hm2_axilite_int.vhd#L318

It would be really nice to have a native axi interface right into the hostmot2 component, which I guess we can do since this repo doesn't have to support pci, uart, or ethernet connected components.

dkhughes commented 8 years ago

@the-snowwhite

THe Really important difference is that I added a load dtbo file as the first hm2_register callback function. To use Instead of the load firmware (.rbf) bitfile.

For this to work it requires the: /config/device-tree/overlays/uiox folder to have been created first.

I think we have a case of toma-y-to, toma-h-to here. The current driver is loading a dtbo by copying the name to the overlay/path directory. Rather than adding a new function hook in higher levels, I just reused the existing one. It doesn't directly load the firmware, in fact you can see it create the folder structure in configfs when it registers. We're doing exactly what your saying. I'm not sure where the difference is? The current ol driver just wraps up the configfs creation/cleanup - it never actually sees the bitfile, only the name of the dtbo.

Looking back at the code, we could even eliminate the char * firmware that I had to add, since we can write the contents of the dtbo directly to the node in the created overlay folder as demonstrated by @mhaberler when he was using cat instead of echo like I was.

cdsteinkuehler commented 8 years ago

On 5/25/2016 8:53 AM, dkhughes wrote:

My priorities are to get the existing Mesa VHDL code integrated into
an SoC+FPGA build chain with as little modification as possible, while
making it as easy as possible to craft a new configuration and have it
"trickle down" into firmware packages, uSD images, etc. in the hopes
of making something usable enough we can gain real-world users.

Totally agree.

Once this foundation is in place, I'd be happy to see the internal
tri-state buses removed and switched to separate input and output
buses (for both the I/O pins and the register bus).

Can the socfpga (altera) side support direct axi bus components easily from qsys?

Yes, easily.

It would be really nice to have a native axi interface right into the hostmot2 component

Agreed, sort-of.

I'd rather see a full split of the read/write buses but otherwise leaving them as-is. That would make it possible to hook up to a full performance AXI or PCIe bus (with simultaneous read/write) while still easily being able to tie to existing Mesa I/O buses like PCI, Ethernet, and SPI.

It's probably wise to not exclude potential devices like the Xylotex board or the RPi3 SPI FPGA board someone is working on with LinuxCNC, and even if these boards go in a different repository, keeping the hostmot2 code identical between them would help with ongoing maintenance.

Charles Steinkuehler charles@steinkuehler.net

the-snowwhite commented 8 years ago

@cdsteinkuehler thanks for the merge, however I have to put in bugfix follow up commit to enable the full functionality, the second commit in that line is adding your 4x7I76 DB25 config which also showed up as 66% of the fpga in my compile. Third and last in that pipeline is ading a 2 port, 34 pin, 1 GPIO, 2 led DB25 muxed config.(that enables compiling 34pin and 68 pin configs with straight or db25 style I/O mux).

My reasoning behind focusing on I/O line muxing right now is that I find it very unpractical to have to create a new pinfile, and then compile a new bitfile, just if I want to reroute some I/O wires between say a pwm and a stepper core, or like right now the very bloated straight <> DB25 static mux built in, which also needs to create a static bitfile for each option.

Even more strongly the way the I/Os are routed right now excludes any possibility of design partitioning:

An elegant solution could for example be to have the mux as a dynamic swappable partition, however this is also not possible, as any kind of partial reconfiguration, has functional design partitioning as first basic step to get right.

As the hostmot2 software and hdl sources all ready has everything needed built in, except for missing a (~36 bit ? mux register per 34 pin GPIO), I invite you to look at the thoughts I have on creating this mod in a non destructive transparant fashion here:

Is it viable to add (Hostmot2) pinmuxing to the

@dkhughes About the dtbo loading instead of .rbf loading I think we are on the same page, I have never had any issues with your hm2_soc_ol driver .. except mistaking the l in the end of the name for a 1 ... (+ I also find it very nice that it removes the uio device node after running machinekit :-) )

So its just confusing for me to see that there should be any problems with reading the needed parameters directly out of either a reverse compiled .dtbo and or the memmapped hostmot2 memory register map...

@cdsteinkuehler

About axi:

I'd rather see a full split of the read/write buses but otherwise leaving them as-is.

the read write busses are totally split up and independent dedicated in / out busses afaiks, The problem is the address bus that is shared for both read and writes, which seems to disable the simultaneous read write capability ?

the-snowwhite commented 8 years ago

Bugfix PR here:

https://github.com/machinekit/mksocfpga/pull/37

the-snowwhite commented 8 years ago

On 24/05/16 07:00, Michael Haberler wrote:

@the-snowwhite https://github.com/the-snowwhite ok let's talk about what is in mk/mk because I tend to get lost in other information bits and pieces floating around:

how is this https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/mesa-hostmot2/hm2_soc_ol.c#L225-L283 conceptually different from your

|rc = run_shell("/bin/mkdir /config/device-tree/overlays/%s", fpga_hm2_drv); |

above /except for the startup phase where it is called/ (other than @dkhughes https://github.com/dkhughes code being super robust about closing race conditions)

then, further above we're discussing what to do in which phase so we're not far apart, the result is going to be the same

but here is another angle: every single hm2 lowlevel driver which might support firmware loading, and all the configs use the |config="firmware= other args"| method. We should strive for keeping that even if it incurs some minimal effort, and I think @dkhughes https://github.com/dkhughes 's idea is minimal in impact.

If 'firmware=foo" refers to a dtbo called foo, or a firmware blob called foo is irrelevant from a user perspective as long as the right thing happens, which does IMO https://github.com/machinekit/machinekit/blob/master/configs/hm2-soc-stepper/5i25-socfpga.ini#L12.

Well first I would like to narrow down the appearance of my proposal to only use .dtbo firmware loading on the mksocfpga 4.1+ kernel revisions.

Since I first interpreted the _ol extension to @dkhughes https://github.com/dkhughes driver code as _o1, It never occurred to me to interpret that as meaning overlay ?, if that is correct I would like to suggest extending that to the more verbose _ovl , which could have made that genial change more appear ant and obvious. () at least for me.

About naming:

Around the new config style there seems to have developed some sort of soc related comprehensive naming style (perhaps missing the number of physical gpios and their number of pins ?).

Suggestion: Making it very clear that the hm2_soc driver is only for direct fpga-bitfile loading,(no driver loading, no device-tree).

And the newer _o(v)l driver is currently only for .dtbo based start-up with automatic driver and firmware loading(device-tree based).

?

AFAICT your proposal would change this /only/ for the hm2_soc_ol driver to move the firmware argument to a /separate/ driver command line argument. That needs to be documented as an exception /only/ for this driver. Why - if we can achieve compatibility with minor effort?

I do not understand this ..

I do not exclude I am overlooking something but frankly I cannot currently see it?

Hmm I may also have expressed myself incorrectly, earlier.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/machinekit/mksocfpga/issues/25#issuecomment-221166931

cdsteinkuehler commented 8 years ago

I believe various recent changes have resolved this issue, and there should be no more modifying the (global) HW/hm2/hostmot2.vhd, which has already been reverted to it's upstream version from Mesa.net (with no default settings for any of the VHDL generics).

I'm therefore considering this issue closed. (Hooray! :-) )