| --- Log opened Tue Mar 29 00:00:56 2016 | ||
| -!- shorne_ is now known as shorne | 01:46 | |
| olofk | wallento: Couldn't you just instantiate many gpio modules instead? That way you can keep the current driver | 02:23 |
|---|---|---|
| olofk | Regarding the OpenRISC System Information Module, I think that's a really good idea, and I have been thinking about that too. Just make sure you check if there are any similar ideas already that we can use, so that we don't have to maintain a separate file format and tools for this | 02:24 |
| olofk | I'm thinking of device trees and sdb for example | 02:24 |
| olofk | And I like the switchbox idea. Really cool | 02:27 |
| olofk | wallento: Also, now when you have started contributing stuff to FuseSoC (and thanks for that!!), I realize how much stuff I have planned but never written down | 02:28 |
| olofk | Generators, versioning, deprecating the .system file, proper testbench sections, a property-fetcher api... just the things I could think of straight away :) | 02:29 |
| olofk | Of those, versioning and the property-fetcher api is most important | 02:30 |
| olofk | And with the latter I mean that it should be possible to query FuseSoC core information about a core | 02:30 |
| olofk | Like fusesoc get-property wb_intercon-1.0 core_root | 02:31 |
| olofk | Or something like that | 02:31 |
| olofk | That would make it much easier to add script hooks that can be run at different stages | 02:33 |
| olofk | Like wb_intercon_gen | 02:33 |
| olofk | Currently you have to know where it is, but if we can run it from `fusesoc get wb_intercon-1.0 core_root`/sw/wb_intercon_gen it would be much easier. | 02:34 |
| olofk | Everything that needs some kind of transformation before being sent to the EDA tool would benefit | 02:35 |
| olofk | Versioning goes without saying. The situation is pretty horrible right now :) | 02:35 |
| olofk | Oh, and I hugely appreciate that you created your own repo for your stuff instead of forking orpsoc_cores. That makes it easier for me to just test it as an overlay while having my regular orpsoc_cores in the bottom | 02:37 |
| wallento | olofk: by having the gpio banks mapped to page boundaries, I can stick with the current driver, right? Its more scalable in my opinion | 02:40 |
| wallento | regarding the system module I will start with the base registers | 02:41 |
| wallento | and barebox may use this to assemble the dts if desired | 02:41 |
| wallento | I will have a look how ARM solved it | 02:41 |
| wallento | regarding the extra transformation, vivado is really great | 02:42 |
| olofk | Yes, all OSs and baremetal libc implementation may be interested in this, so maybe there's a semistandard way | 02:42 |
| wallento | you just feed in the xci (which is ipxact) and it generates automatically | 02:42 |
| olofk | Yes, that's handy | 02:43 |
| olofk | Just sucks that we can't have a nice vendor-neutral way for this | 02:43 |
| wallento | can you add me to the fusesoc repo and create the wiki? | 02:43 |
| wallento | we can collect ideas there | 02:44 |
| wallento | and turn them into issues | 02:44 |
| wallento | yeah, thats right, especially clock generation should be easy to have a common way | 02:44 |
| olofk | See if you have access now | 02:44 |
| wallento | yep, I do, thanks! | 02:45 |
| olofk | Clock generation would be nice, but it's one of those things where I think the pain of implementing a clever method for this far outweights the benefits right nwo | 02:45 |
| wallento | yep | 02:45 |
| wallento | and the macros are pretty simple to use | 02:45 |
| olofk | wallento: I just saw your naming scheme with the slashes in the .core file. I had misunderstood a bit when I read the commit log | 02:47 |
| olofk | I don't think it's a good idea to do it that way. In that case, I'd rather go for full IP-XACT instead and define vendor,library,name,version components in the .core file | 02:48 |
| olofk | The [provider] could then use this to assemble the path to the core | 02:49 |
| wallento | yes, then we should do it that way, but plain names are not scalable | 02:49 |
| olofk | Or am I missing some point here | 02:49 |
| olofk | Totally agree | 02:49 |
| wallento | nope, the right direction | 02:49 |
| wallento | I was thinking a free naming just makes life easy now | 02:50 |
| wallento | to play around with fallback directories/library providers | 02:50 |
| olofk | can you explain? | 02:50 |
| wallento | like I am planning for librecore | 02:50 |
| wallento | I was lazy and want to add wallento/gpio | 02:51 |
| wallento | and if it is not found locally in any of cores_root | 02:51 |
| wallento | then it would query api.librecores.org for a core named wallento/gpio | 02:51 |
| wallento | querying for vendor=wallento, library=gpio, name=gpio is even better I think :) | 02:52 |
| olofk | I think that's the way to go | 02:52 |
| wallento | but maybe we can define a naming scheme for this | 02:52 |
| wallento | like a tuple | 02:52 |
| wallento | to make dependencies easier | 02:52 |
| olofk | Oh, if you want to submit a semi-trivial commit, it would be great to have license and tags in the .core file | 02:52 |
| olofk | tuple? | 02:53 |
| wallento | oh, triplet: wallento-gpio-gpio | 02:53 |
| olofk | Ah yes | 02:53 |
| olofk | I've been spending hours writing down pros and cons of which separator to use :) | 02:53 |
| wallento | otherwise the dependencies look like [vendor=...] or so | 02:53 |
| wallento | hyphen always works :) | 02:54 |
| wallento | or slash | 02:54 |
| wallento | I would vote for slash, but we can put up a discussion in the wiki | 02:54 |
| olofk | hyphen doesn't work. We already have cores with hyphen in their names | 02:54 |
| olofk | But I came to the same conclusion as you, that we want a triplet | 02:55 |
| wallento | then vandor/library/name@version? | 02:55 |
| olofk | So, using gentoo style dependency syntax, we can depend on >=wallento:gpio:gpio-1.0 | 02:55 |
| olofk | I'm going to check with gentoo btw, because they have an ebuild parsing python library as one of their gsoc projects this year. There's a possibility we could pull out some dependency parsing code from that | 02:57 |
| olofk | gtg | 02:57 |
| andrzejr | olofk, about property fetching and scripting - one thing I really like in the current design of fusesoc is that each core takes care of itself *only*. That makes the whole mechanism well encapsulated and easy to use. If we start adding scripts that do something to one core based on definition of another core we will open a can of worms. | 03:45 |
| andrzejr | Not saying that will not work (it will!) but we will end up with large number of dependencies between cores, race conditions, conflicts. | 03:46 |
| andrzejr | The alternative is simply to introduce extra (perhaps generated) cores, even if they contain little data. | 03:47 |
| andrzejr | For example, for wb_interconn we could add a core systems/de0_nano/de0_nano_interconn that is fully generated. The top-level core would only have to depend on it. | 03:51 |
| andrzejr | If that looks similar to "generator providers" - yes it is. After working with them for a while I much more prefer this approach to scripting. In fact, I would go a step further and moved patching to seperated cores ("patch generators"). | 03:55 |
| wallento | I think I am generally along the lines of andrzejr | 04:35 |
| wallento | maybe it would be good to sketch some examples what may be useful and what may cause more pain | 04:36 |
| wallento | what confuses me still a bit is how to handle versioning | 04:49 |
| wallento | for remote fetching I think this is easy, just api.librecores.org/cores/wallento/gpio/gpio/v2.1 | 04:49 |
| wallento | which will return a different core file | 04:49 |
| wallento | but for core files in the file tree there will be different gpio-<version>.core files? | 04:50 |
| wallento | I have drafted a little bit: https://github.com/olofk/fusesoc/wiki/NewModuleNaming | 04:56 |
| wallento | and that: https://github.com/olofk/fusesoc/wiki/Directories | 05:08 |
| GeneralStupid | play | 05:32 |
| mithro | wallento / olofk: We are kind of interested in switching or1k softcpu for use in our HDMI2USB firmware (because we are interested in running Linux on it) | 07:19 |
| mithro | I think I previously explained we currently use the lm32 one because the arch is in the upstream toolchain | 07:19 |
| wallento | is there no Linux for lm32? | 07:20 |
| mithro | wallento: Not really, the m-lab guys kind of get a ucLinux version working a long while back (I think back in 2012? - https://m-labs.hk/milkymist-wiki/wiki/index.php%3Ftitle=Milkymist_Linux_cheat_sheet.html and https://m-labs.hk/milkymist-wiki/wiki/index.php%3Ftitle=Milkymist_Linux_cheat_sheet.html ) | 07:24 |
| mithro | But really, we'd like to try and reuse other people's work as much as possible :) | 07:24 |
| mithro | The less stuff we have to maintain ourselves, the better :P | 07:25 |
| wallento | thats a good approach :) | 07:26 |
| wallento | regarding gpio I think I will try to be compliant to this one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-generic.c?id=refs/tags/v4.5 | 07:31 |
| mafm | wallento: did anybody apply to reimplemente the GCC port in GSoC? :) | 07:33 |
| wallento | unfortunately not :) | 07:34 |
| mithro | There was something about GPIOs on LWN recently | 07:34 |
| stekern | wallento: iirc, the gpio core we've used so far is compliant with that | 07:34 |
| wallento | great | 07:34 |
| wallento | I will just extend it a bit | 07:34 |
| stekern | as long as you instantiate one core per 8 GPIO's | 07:34 |
| wallento | yeah, I will just provide banks of 8 GPIOs aligned to page boundaries | 07:35 |
| stekern | the problem with that driver is just that it doesn't have device-tree support | 07:35 |
| wallento | yeah, I see | 07:36 |
| wallento | there is quite a number of gpio drivers | 07:36 |
| wallento | do you know if any of them support device tree | 07:37 |
| stekern | I bet some of them do, but I don't know which | 07:37 |
| mithro | Ahh | 07:38 |
| mithro | The kernel's representation of general-purpose I/O (GPIO) devices has been massively reworked; the gpio_chip structure is a proper device within the device model now. There is a new ABI for getting information about the GPIOs on the system, but some work remains to be done. As Linus Walleij noted: "We can now discover GPIOs properly from userspace. We still | 07:38 |
| mithro | have not come up with a way to actually *use* GPIOs from userspace." See tools/gpio/lsgpio.c for an example of the new ABI; note that the old sysfs-based ABI is now considered obsolete (even though it has not yet been completely replaced). | 07:38 |
| mithro | https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a46712aa99594eabe1e9aeedf115dfff0db1dfd | 07:41 |
| mithro | According to the stats, the GPIO subsystem has had a *lot* of work recently | 07:44 |
| _franck__ | gpio can be used from userspace using sysfs | 07:44 |
| mithro | Linus Walleij topped the by-changesets list with a lot of low-level work, mostly near the GPIO subsystem and drivers that use it. -- 2% of the changes in Linux 4.5 :P | 07:44 |
| mithro | _franck__: "note that the old sysfs-based ABI is now considered obsolete (even though it has not yet been completely replaced)." | 07:45 |
| _franck__ | ok :) | 07:45 |
| wallento | yeah, I saw the sysfs stuff | 07:46 |
| wallento | mmh | 07:47 |
| wallento | "We still have not come up with a way to actually *use* GPIOs from userspace." | 07:48 |
| mithro | wallento: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-generic.c?id=refs/tags/v4.5 | 07:49 |
| wallento | yep, thats the one that I originally wanted to adopt | 07:49 |
| mithro | The expectation is that in at least some cases this will be used with roll-your-own ASIC/FPGA logic in Verilog or VHDL. | 07:49 |
| wallento | but it is not compliant with the new GPIO devices stuff, right? | 07:50 |
| mithro | Why is there a stupid alien in the comment at the top!? | 07:50 |
| wallento | hehe, thats your facebook messenger replacing it :) | 07:51 |
| mithro | wallento: I found that linked from the GPIO refactor patch I just linked? | 07:51 |
| wallento | ah, I see | 07:52 |
| wallento | https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/gpio/gpio-generic.c?id=1a46712aa99594eabe1e9aeedf115dfff0db1dfd | 07:52 |
| wallento | yep | 07:52 |
| mithro | So yeah, you just might need to be on Linux 4.6 | 07:52 |
| wallento | okay, thats a good target | 07:53 |
| wallento | and the device is really simple | 07:53 |
| wallento | so it should work | 07:53 |
| mithro | I was really hoping we would get a GSoC student interested in doing bring up of Linux on our firmware :P | 07:53 |
| wallento | lets hope they find a way to actually access GPIO then until 4.6 is released :-p | 07:53 |
| mithro | wallento: I think it will be 4.7 before that happens :P | 07:54 |
| wallento | and the legacy stuff is deprecated then | 07:54 |
| wallento | its like when linux containers were introduced | 07:54 |
| wallento | they were not fully implemented, but the legacy stuff was removed already | 07:54 |
| wallento | what seems missing in gpio-generic.c is interrupts | 07:58 |
| mithro | wallento: sounds like you should send that Linus guy an email and see what he thinks? | 08:03 |
| wallento | hehe | 08:03 |
| wallento | yep | 08:03 |
| wallento | or have a look at the gaisler stuff | 08:04 |
| mithro | wallento: not *the* Linus, his a different one :P | 08:04 |
| wallento | I realized :) | 08:04 |
| wallento | the gaisler one has device tree support: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt | 08:04 |
| wallento | I think you are right, mithro, I will just ask this guy | 08:06 |
| mithro | wallento: Then if you send him a patch, he can't object ;) | 08:06 |
| wallento | hehe | 08:07 |
| wallento | interesting thing also this pincontrol | 08:09 |
| wallento | https://www.kernel.org/doc/Documentation/pinctrl.txt | 08:09 |
| wallento | I will do my baremetal homework first :) | 08:10 |
| mithro | yeah -- First and foremost, the two subsystems can be used as completely orthogonal, see the section named "pin control requests from drivers" and "drivers needing both pin control and GPIOs" below for details. But in some situations a cross-subsystem mapping between pins and GPIOs is needed. | 08:15 |
| mithro | That doc makes my head hurt :P | 08:18 |
| wallento | yeah, its probably something you must start reading after doing the hardware | 08:44 |
| wallento | because your brain is so deeply fucked then | 08:44 |
| wallento | https://github.com/wallento/pmod_switchbox/blob/master/pmod_switchbox.sv | 09:48 |
| wallento | for loop hell :) | 09:48 |
| wallento | olofk: you are the expert. $clog2(1)==1, right? | 10:37 |
| wallento | ah, no its 0 | 10:38 |
| -!- blueCmd_ is now known as blueCmd | 15:11 | |
| olofk | wallento: Yes, $clog2(1) == 0, unless you're on an older version of Vivado... or an older version of ISE. Fucking Xilinx fucking crappy quality control | 17:30 |
| olofk | wallento, andrzejr: The reason that I want to go with the property fetching stuff is that I think it's good to make it possible to do stuff that FuseSoC doesn't yet support. Some of this functionality will eventually move into FuseSoC, but this will serve as a sort of staging area | 17:32 |
| olofk | And some things will never be implemented in FuseSoC because they are too specific to a core. | 17:33 |
| olofk | And currently we export some environment variables to the script hooks, but I came to the conclusion that this isn't really scalable | 17:33 |
| olofk | Having a proper generator framework is a better solution (either via providers, or through a separate mechanism), but script hooks will be a poor-mans version of that | 17:35 |
| olofk | I think that andrzejr's method of using the providers for generating stuff is really clever, but there is one thing that is missing with that solution | 17:37 |
| olofk | Currently all providers must be part of FuseSoC. I want each core to be able to register themselves as a generator, so when FuseSoC parses the core libraries, it will find all cores which contain generators | 17:38 |
| olofk | These can be used in two ways | 17:38 |
| olofk | Either by calling them on the command-line, e.g. fusesoc gen name_of_generator --options --for --generator | 17:39 |
| olofk | Or adding a section to the top-level core to run the generator on the fly | 17:39 |
| olofk | I've outlined this before a few times, but now that we have a wiki, I guess that should be the best place to put up a discussion | 17:50 |
| olofk | hmm.. one option I haven't even considered is to let cores register themselves as providers instead. That might be the solution | 18:06 |
| olofk | Time to sleep | 18:09 |
| -!- Netsplit *.net <-> *.split quits: rokka | 19:05 | |
| --- Log closed Wed Mar 30 00:00:58 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!