IRC logs for #openrisc Tuesday, 2016-03-29

--- Log opened Tue Mar 29 00:00:56 2016
-!- shorne_ is now known as shorne01:46
olofkwallento: Couldn't you just instantiate many gpio modules instead? That way you can keep the current driver02:23
olofkRegarding 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 this02:24
olofkI'm thinking of device trees and sdb for example02:24
olofkAnd I like the switchbox idea. Really cool02:27
olofkwallento: 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 down02:28
olofkGenerators, versioning, deprecating the .system file, proper testbench sections, a property-fetcher api... just the things I could think of straight away :)02:29
olofkOf those, versioning and the property-fetcher api is most important02:30
olofkAnd with the latter I mean that it should be possible to query FuseSoC core information about a core02:30
olofkLike fusesoc get-property wb_intercon-1.0 core_root02:31
olofkOr something like that02:31
olofkThat would make it much easier to add script hooks that can be run at different stages02:33
olofkLike wb_intercon_gen02:33
olofkCurrently 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
olofkEverything that needs some kind of transformation before being sent to the EDA tool would benefit02:35
olofkVersioning goes without saying. The situation is pretty horrible right now :)02:35
olofkOh, 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 bottom02:37
wallentoolofk: by having the gpio banks mapped to page boundaries, I can stick with the current driver, right? Its more scalable in my opinion02:40
wallentoregarding the system module I will start with the base registers02:41
wallentoand barebox may use this to assemble the dts if desired02:41
wallentoI will have a look how ARM solved it02:41
wallentoregarding the extra transformation, vivado is really great02:42
olofkYes, all OSs and baremetal libc implementation may be interested in this, so maybe there's a semistandard way02:42
wallentoyou just feed in the xci (which is ipxact) and it generates automatically02:42
olofkYes, that's handy02:43
olofkJust sucks that we can't have a nice vendor-neutral way for this02:43
wallentocan you add me to the fusesoc repo and create the wiki?02:43
wallentowe can collect ideas there02:44
wallentoand turn them into issues02:44
wallentoyeah, thats right, especially clock generation should be easy to have a common way02:44
olofkSee if you have access now02:44
wallentoyep, I do, thanks!02:45
olofkClock 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 nwo02:45
wallentoand the macros are pretty simple to use02:45
olofkwallento: I just saw your naming scheme with the slashes in the .core file. I had misunderstood a bit when I read the commit log02:47
olofkI 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 file02:48
olofkThe [provider] could then use this to assemble the path to the core02:49
wallentoyes, then we should do it that way, but plain names are not scalable02:49
olofkOr am I missing some point here02:49
olofkTotally agree02:49
wallentonope, the right direction02:49
wallentoI was thinking a free naming just makes life easy now02:50
wallentoto play around with fallback directories/library providers02:50
olofkcan you explain?02:50
wallentolike I am planning for librecore02:50
wallentoI was lazy and want to add wallento/gpio02:51
wallentoand if it is not found locally in any of cores_root02:51
wallentothen it would query for a core named wallento/gpio02:51
wallentoquerying for vendor=wallento, library=gpio, name=gpio is even better I think :)02:52
olofkI think that's the way to go02:52
wallentobut maybe we can define a naming scheme for this02:52
wallentolike a tuple02:52
wallentoto make dependencies easier02:52
olofkOh, if you want to submit a semi-trivial commit, it would be great to have license and tags in the .core file02:52
wallentooh, triplet: wallento-gpio-gpio02:53
olofkAh yes02:53
olofkI've been spending hours writing down pros and cons of which separator to use :)02:53
wallentootherwise the dependencies look like [vendor=...] or so02:53
wallentohyphen always works :)02:54
wallentoor slash02:54
wallentoI would vote for slash, but we can put up a discussion in the wiki02:54
olofkhyphen doesn't work. We already have cores with hyphen in their names02:54
olofkBut I came to the same conclusion as you, that we want a triplet02:55
wallentothen vandor/library/name@version?02:55
olofkSo, using gentoo style dependency syntax, we can depend on >=wallento:gpio:gpio-1.002:55
olofkI'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 that02:57
andrzejrolofk, 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
andrzejrNot saying that will not work (it will!) but we will end up with large number of dependencies between cores, race conditions, conflicts.03:46
andrzejrThe alternative is simply to introduce extra (perhaps generated) cores, even if they contain little data.03:47
andrzejrFor 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
andrzejrIf 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
wallentoI think I am generally along the lines of andrzejr04:35
wallentomaybe it would be good to sketch some examples what may be useful and what may cause more pain04:36
wallentowhat confuses me still a bit is how to handle versioning04:49
wallentofor remote fetching I think this is easy, just
wallentowhich will return a different core file04:49
wallentobut for core files in the file tree there will be different gpio-<version>.core files?04:50
wallentoI have drafted a little bit:
wallentoand that:
mithrowallento / 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
mithroI think I previously explained we currently use the lm32 one because the arch is in the upstream toolchain07:19
wallentois there no Linux for lm32?07:20
mithrowallento: Not really, the m-lab guys kind of get a ucLinux version working a long while back (I think back in 2012? - and )07:24
mithroBut really, we'd like to try and reuse other people's work as much as possible :)07:24
mithroThe less stuff we have to maintain ourselves, the better :P07:25
wallentothats a good approach :)07:26
wallentoregarding gpio I think I will try to be compliant to this one:
mafmwallento: did anybody apply to reimplemente the GCC port in GSoC? :)07:33
wallentounfortunately not :)07:34
mithroThere was something about GPIOs on LWN recently07:34
stekernwallento: iirc, the gpio core we've used so far is compliant with that07:34
wallentoI will just extend it a bit07:34
stekernas long as you instantiate one core per 8 GPIO's07:34
wallentoyeah, I will just provide banks of 8 GPIOs aligned to page boundaries07:35
stekernthe problem with that driver is just that it doesn't have device-tree support07:35
wallentoyeah, I see07:36
wallentothere is quite a number of gpio drivers07:36
wallentodo you know if any of them support device tree07:37
stekernI bet some of them do, but I don't know which07:37
mithroThe 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 still07:38
mithrohave 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
mithroAccording to the stats, the GPIO subsystem has had a *lot* of work recently07:44
_franck__gpio can be used from userspace using sysfs07:44
mithroLinus 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 :P07: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
wallentoyeah, I saw the sysfs stuff07:46
wallento"We still have not come up with a way to actually *use* GPIOs from userspace."07:48
wallentoyep, thats the one that I originally wanted to adopt07:49
mithroThe 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
wallentobut it is not compliant with the new GPIO devices stuff, right?07:50
mithroWhy is there a stupid alien in the comment at the top!?07:50
wallentohehe, thats your facebook messenger replacing it :)07:51
mithrowallento: I found that linked from the GPIO refactor patch I just linked?07:51
wallentoah, I see07:52
mithroSo yeah, you just might need to be on Linux 4.607:52
wallentookay, thats a good target07:53
wallentoand the device is really simple07:53
wallentoso it should work07:53
mithroI was really hoping we would get a GSoC student interested in doing bring up of Linux on our firmware :P07:53
wallentolets hope they find a way to actually access GPIO then until 4.6 is released :-p07:53
mithrowallento: I think it will be 4.7 before that happens :P07:54
wallentoand the legacy stuff is deprecated then07:54
wallentoits like when linux containers were introduced07:54
wallentothey were not fully implemented, but the legacy stuff was removed already07:54
wallentowhat seems missing in gpio-generic.c is interrupts07:58
mithrowallento: sounds like you should send that Linus guy an email and see what he thinks?08:03
wallentoor have a look at the gaisler stuff08:04
mithrowallento: not *the* Linus, his a different one :P08:04
wallentoI realized :)08:04
wallentothe gaisler one has device tree support:
wallentoI think you are right, mithro, I will just ask this guy08:06
mithrowallento: Then if you send him a patch, he can't object ;)08:06
wallentointeresting thing also this pincontrol08:09
wallentoI will do my baremetal homework first :)08:10
mithroyeah -- 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
mithroThat doc makes my head hurt :P08:18
wallentoyeah, its probably something you must start reading after doing the hardware08:44
wallentobecause your brain is so deeply fucked then08:44
wallentofor loop hell :)09:48
wallentoolofk: you are the expert. $clog2(1)==1, right?10:37
wallentoah, no its 010:38
-!- blueCmd_ is now known as blueCmd15:11
olofkwallento: Yes, $clog2(1) == 0, unless you're on an older version of Vivado... or an older version of ISE. Fucking Xilinx fucking crappy quality control17:30
olofkwallento, 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 area17:32
olofkAnd some things will never be implemented in FuseSoC because they are too specific to a core.17:33
olofkAnd currently we export some environment variables to the script hooks, but I came to the conclusion that this isn't really scalable17:33
olofkHaving 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 that17:35
olofkI 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 solution17:37
olofkCurrently 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 generators17:38
olofkThese can be used in two ways17:38
olofkEither by calling them on the command-line, e.g. fusesoc gen name_of_generator --options --for --generator17:39
olofkOr adding a section to the top-level core to run the generator on the fly17:39
olofkI'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 discussion17:50
olofkhmm.. one option I haven't even considered is to let cores register themselves as providers instead. That might be the solution18:06
olofkTime to sleep18:09
-!- Netsplit *.net <-> *.split quits: rokka19:05
--- Log closed Wed Mar 30 00:00:58 2016

Generated by 2.15.2 by Marius Gedminas - find it at!