pigeons has quit [Quit: No Ping reply in 180 seconds.]
illwieckz has quit [Quit: Ça va couper chérie…]
pigeons has joined #neo900
illwieckz has joined #neo900
illwieckz has joined #neo900
illwieckz has quit [Changing host]
chomwitt has quit [Ping timeout: 265 seconds]
Oksana has quit [Read error: Connection reset by peer]
Albert has joined #neo900
illwieckz has quit [Quit: Ça va couper chérie…]
illwieckz has joined #neo900
Albert has quit [Ping timeout: 252 seconds]
illwieckz has quit [Ping timeout: 245 seconds]
Oksana has joined #neo900
illwieckz has joined #neo900
<Oksana>
Very neat! https://neo900.org/news/2016-week-42 And could you please maybe turn #channel into IRC links? Could be handy, for those with irc:// handling properly configured.
<illwieckz>
well, I put money in this project because all my servers are running debian, my routers are running debian, my desktop is running debian, my laptop is running debian, even my studio clocks are running debian, and this project promised to put debian on my phone, so if it"s devuan it's not my project: I expected to be able to unify my system management across devices, and devuan is from the start not about unifying
<Oksana>
Well, ask somebody to create Debian image for this device. I am sure that if Devuan image was created, Debian is somewhere, too.
<DocScrutinizer05>
you're aware you can "upgrade" from devuan to debian by simply installing systemd and all its dependencies? You also are aware that Neo900 UG only ships a board support package and supports community to port all FOSS systems anybody is interested to port?
<Oksana>
Just keep in mind that some people are strongly opinionated against systemd, pulseaudio, and such. And see? Debian=Devuan+systemd, easy. Devuan is not going to lock you out of Debian, not going to even try.
<DocScrutinizer05>
alos please note that for all that matters here, Neo900==BeagleBoard-xM, and for the latter I'm pretty sure a debian image exists since ages
<DocScrutinizer05>
also*
<DocScrutinizer05>
*IF* anything been promised then that was Maemo compatibility on the hardware level, for the obvious reason that we think Maemo is the most open and functional mature Debian-like Phone OS available out there
<DocScrutinizer05>
but don't worry, there will be a Debian for sure. No faintest doubt about that
<DocScrutinizer05>
I'm just curious: what makes you think that "devuan is from the start not about unifying"?
<DocScrutinizer05>
it's rather that I think Debian since systemd is not about embedded anymore, they even dropped armel support afaik, for the reasoning of "not many ARM CPUs out there that need it, so the overhead for supporting it is considered too high in relation to the user count"
<DocScrutinizer05>
((upgrade to systemd)) The problem is that Maemo (Neo900's recommended OS, debian based) is pre-systemd and has relevant core functionality using cgroups in a way that makes systemd (who mandates exclusive use of cgroups) incompatible to Maemo. So what Devuan does is conserving the pre-systemd state of Debian, and that's the "Debian" Maemo needs to base on, while true Debian will more and more drift away from Maemo and leaves it behind.
<DocScrutinizer05>
Who's to blame?
<DocScrutinizer05>
in 5 years Debian will have minimum system requirements that forbit to install it on any single core system as well as on systems with less than 32 GB RAM
<DocScrutinizer05>
and it already requires a root partition of several GB size, since in their wisdom freedesktop and systemd cabal decided that /usr/ has to be a subdir of root dir instead of the late-mounted separate filesystem/volume it been specified to be, by FHS
<DocScrutinizer05>
this in particular rules out recent Debian as the OS of choice for basically all embedded systems which typically only have a maybe 512MB or a huge 1GB of root NAND stroage to boot from
<DocScrutinizer05>
illwieckz: but don't worry, our intentions are exactly identical to yours, so we will strive hard to make stuff work in a way that for sure will also please you
<Wizzup>
I may not make CCC, but I never miss FOSDEM
<DocScrutinizer05>
well, how900 has his own ideas about what's newsletter worthy and what not. The general common sense in Neo900 seems to not spam the customers with too many emails since that's a rude thing to do
<DocScrutinizer05>
Wizzup: I'm a very shy person
<Wizzup>
well, when was the last email?
<DocScrutinizer05>
even getting worse each year
<Wizzup>
one email a month is not spamming
<DocScrutinizer05>
yes, I wholeheartedly agree. how900, what do you think would qualify for a newsletter email?
<DocScrutinizer05>
maybe our recent discussion with RMS and paulk will eventually provide nice material for a newsletter
<ceene>
i'm finding linux' gpio support severely lacking
<DocScrutinizer05>
how900: I don't know how much trouble is maintaining a second ML which is higher volume than the one we are running already
<DocScrutinizer05>
ceene: well, maemo has "switches" for that, which aiui is a thing that didn't make it upstream
<DocScrutinizer05>
looks like, can't find anything similar in my RPM PC system
<ceene>
it's pretty cumbersome when you need to read 12 bits
<DocScrutinizer05>
aah ok
<ceene>
or maybe 32
<ceene>
when i'd just like to read them all as an int32_t, or maybe as for int8_t
<ceene>
s/for/four/
<ceene>
also, kernel interface is shitty
<ceene>
it seems that it can only manage one gpio at a time
<ceene>
even if underlying hardware can manage all lanes at the same time
<DocScrutinizer05>
yes
<ceene>
i can't change 0000 to 1111 in just one instruction
<ceene>
i need to do four changes
<ceene>
even though i know for a fact that the hardware below that is able to change all four bits at the same time
<DocScrutinizer05>
you need a driver for such stuff
<ceene>
but there's no kernel interface for that
<ceene>
and gpio interface doesn't support that
<ceene>
so i can't write a standard gpio driver that allows to do that
<DocScrutinizer05>
4 gpio are any sort of bus or interface, so not exactly appropriate for a generic GPIO API. Well, at least arguable
<ceene>
it is what it is, a bunch of gpios that have a particular meaning and that should be able to be associated to manage at the same time, if the underlying hardware allows it
<ceene>
if those 4 gpio are attached to say, a 4 bit counter, it's completely useless to read the 4 bits one at a time
<DocScrutinizer05>
that's why you need a counter driver for that
<ceene>
but that would be a driver that doesn't rely on gpio framework
<ceene>
so, gpio framework is useless
<DocScrutinizer05>
exactly
<DocScrutinizer05>
gpio framework is not useless, it's simply not made and not meant for the purpose you aim at
<ceene>
so even if there's a xilinx-gpio driver, that driver is useless too to implement a counter driver
<ceene>
i don't think i'm asking too much... hardware allows to read and set a bunch of bits of the gpio at the same time
<ceene>
why doesn't the kernel support that?
<ceene>
it's basic gpio controller functionality
<ceene>
there's not much more to a gpio controller
<ceene>
set lanes as input/output/both and read/set them all
<DocScrutinizer05>
and kernel API is supposed to abstract such basics so user can't mess with stuff in a potetially harmful way
<ceene>
but it doesn't, as it's lacking functionality
<DocScrutinizer05>
I failed to convey what I meant to say
<DocScrutinizer05>
functionality is dangerous
<Wizzup>
ceene: the in-kernel gpio framework is quite decent, the userspace one is simple
<Wizzup>
it does work fine, though
<ceene>
i would say lacking that functionality is what is dangeours
<DocScrutinizer05>
userland isn't supposed to have access to such possibly dangerous functionality
<Wizzup>
- lennart poettering
<ceene>
Wizzup: in-kernel gpio framework is lacking multiple bit management at the same time
<ceene>
DocScrutinizer05: not being able to drive or read this four or howmany i need to, is what is dangerous
<DocScrutinizer05>
would I like to have a versatile generic GPIO API? hell yes! Do I think it's a design flaw that no such interface exists? No, the API is supposed to provide higher abstracted level of interface than "users group arbitrary GPIO to their liking"
<DocScrutinizer05>
ceene: then write a driver for it, that's the linux way
<ceene>
i don't understand why you think driving gpios one by one is higher level than driving them all as a bus...
<DocScrutinizer05>
huh?
<DocScrutinizer05>
I think you're using the wrong interface, that's all
<ceene>
there's no other interface, that's the problem
<DocScrutinizer05>
when you want to control a counter (with 4 GPIO) then write a counter driver
<ceene>
there's code written to manage gpio chip controllers
<ceene>
but i can't use that code to write above it a counter driver
<ceene>
even if it's basically 99% of the code i need
<ceene>
so, if i write a counter driver i will start by cp gpio-xilinx.c to counter-through-gpio-xilinx.c
<ceene>
and add one 4-lines function
<DocScrutinizer05>
fine, then you need to only patch 1% of code to make your proper counter driver
<ceene>
yeah, and then we have duped code on the kernel
<ceene>
whatever, it's not you the one i have to convince anyhow...
<DocScrutinizer05>
no, since that codes exactly refers to the 4-GPIO property of that counter, and that is supposed to live *inside* the driver
<ceene>
when that code reads the '4' from the DTS and is made generic
<DocScrutinizer05>
counter driver = 4 grouped GPIO. GPIO driver = single bit
<ceene>
it gets to be exactly the same as standard 1 bit gpio if gpio-width=1 is set on dts
<ceene>
so it's the same thing
<DocScrutinizer05>
please discuss it with kernel devels
<ceene>
i though for a moment that i was ranting so much when the solution already existed :D
<DocScrutinizer05>
not that I know of
<DocScrutinizer05>
I was even unaware of the gpio API Wizzup came up with
<ceene>
ok, this is weird
<ceene>
there exists gpio_chip_set_multiple
<ceene>
but there's no gpio_chip_get_multiple
<DocScrutinizer05>
o.O
<ceene>
* set multiple outputs on the same chip;
<ceene>
* use the chip's set_multiple function if available;
<ceene>
* otherwise set the outputs sequentially;
<ceene>
but there's no counterpart for readyng
<ceene>
reading
<DocScrutinizer05>
weird
<ceene>
well, i guess i can write a patch that does that...
<ceene>
i don't think it's something anyone will oppose to
<DocScrutinizer05>
ceene: what's your (and ahycka's) status regarding layout?
<ceene>
we talked to wpwrak a couple days ago
<ceene>
well, more likely a week
<DocScrutinizer05>
well, I suggest you talk to me
<ceene>
and he told us about a few things that are remaining
<ceene>
and about footprints
<ceene>
ahycka will review all footprints before routing
<ceene>
even if some previous review is desired nonetheless
<DocScrutinizer05>
so did she start with that?
<ceene>
no, not yet, she'll do that as she goes along the routing
<ceene>
review before placing
<ceene>
that's the way she usually does it
<DocScrutinizer05>
oh
<ceene>
it serves two purposes
<DocScrutinizer05>
sounds pretty uneffective
<ceene>
oh, i don't think it is
<ceene>
i believe it's the opposite
<ceene>
reviewing drawings is quite boring
<ceene>
and error prone
<ceene>
when you're checking 2 or 3 componentes, it's okay
<ceene>
when you are checking the 20th in a row
<ceene>
you just don't see the annotations
<ceene>
and everyhing passes your mental filter as "yeah, well, it looks okay"
<DocScrutinizer05>
ell, then did she start layouting yet?
<DocScrutinizer05>
or rather component placement?
<ceene>
repetitive task gets bad results
<ceene>
i think she has a slight idea on lower
<ceene>
but would like to wait for finished schematics
<DocScrutinizer05>
tnhe schematics are finished for all that matters to layout right now
<ceene>
i don't think that's true... a simple pin swap affects routing
<DocScrutinizer05>
pin swap is layouter's job
<DocScrutinizer05>
how would we (schematics editors) know which pin is to be swapped to simplify routing?
<ceene>
i meant a simple change
<DocScrutinizer05>
there will always be "simple changes" - after all this is a prototype and we for sure will need some changes we omly learn about after we did a first layout
<ceene>
ahycka needs to receive a frozen version of the schematics before starting
<ceene>
it doesn't mean they have to be the last schematic there will ever be
<ceene>
but it must be something that is decided that *this* will be manufactured
<DocScrutinizer05>
did you already learn to git-pull?
<ceene>
i.e., a commit hash
<ceene>
if she starts now, she won't do any git pull
<ceene>
if you say commit XXXX is ready to go to routing, then that commit will be routed
<ceene>
but no changes afterwards
<DocScrutinizer05>
no, we can't decide that "this will be manufactured". This is a prototype in development. We will see problems we need to fix only after we inspect the layout
<ceene>
or that would be chaos
<ceene>
there can be revisions of the layout, and even of the schematic after the layout has been finished
<ceene>
and a couple iterations
<ceene>
of course
<DocScrutinizer05>
exactly
<ceene>
but no one can route a schematic that is changing everyday
<ceene>
it makes no sense to start routing something if 20% of the schematics are going to change before routing has finished
<DocScrutinizer05>
you're not supposed to follow any daily changes to the schematics, just pick any time you want and use that version to do a first layout
<DocScrutinizer05>
ther won't be 20% of schematics changing
<DocScrutinizer05>
the schematics are 99,x% stable
<ceene>
ok, but if routing takes, say, 2 months, will it have to be updated with 2 months worth of schematics?
<DocScrutinizer05>
sorry, I don't get that
tsuggs has quit [Ping timeout: 265 seconds]
<ceene>
say ahycka starts routing today what is latest available on git repo
<ceene>
and it takes her two months to complete the routing
<DocScrutinizer05>
I think 7 days old
<ceene>
during those two months, schematics can change
<DocScrutinizer05>
so?
<ceene>
what would you like to happen with the routing she's done?
<ceene>
to be left alone and manufacture that
<ceene>
or to update it to reflect those two months worth of schematic changes?
<DocScrutinizer05>
define "2 months worth of schematics changes"
<ceene>
well, i don't know
<ceene>
it could be swapping a R value, which is trivial
<ceene>
or it could be changing a non trivial component
<DocScrutinizer05>
won't happen
<DocScrutinizer05>
I thimk since a 5 days we got *all* the non trivial components in place
<ceene>
ok
<DocScrutinizer05>
maybe worst case one 20pin chip missing to mux a few signals when we learn we don't have enough pins on a connector
<DocScrutinizer05>
such stuff
<DocScrutinizer05>
not exactly likely that such stuff happens next month anymore
<DocScrutinizer05>
those things also depend on layout since our space constraints determine what can get done and what needs further refinement to fit in
<DocScrutinizer05>
e.g for the above mentioned mux we would run into that when we learn we can't have that B2B connector pin count since it's too large (made up example)
<ceene>
ok, that's reasonable
<DocScrutinizer05>
so I suggest to start footprint checking and component placement which may take quite a while until trace layout even can start
<ceene>
that's true, yes
<DocScrutinizer05>
I don't know how exactly you work, if youplace components one by one and rute them partially, or you place all components first and then layout the frist trace
<ceene>
it depends on the particular board, i think
<DocScrutinizer05>
prolly, yes
<ceene>
last one, the fpga one you saw, was pretty modular
<ceene>
so lots of things were routed offboard
<ceene>
and then placed on the final board
<ceene>
some others, which are more interdependent, are placed first and routed after that
<DocScrutinizer05>
anyway I am pretty sure we got all the chips in and you can start component placement. Routing may change for an occasional mini circuit change for adding a resistor or swapping two pins, but that should not happen anymore in 4 weeks the latest
<ceene>
ok, that's great then
<DocScrutinizer05>
I'm giving the schematics a review this week, and that will introcude some changes but not on a significant BOM level
<ceene>
yes, that kind of thing is expected
<DocScrutinizer05>
:-)
<DocScrutinizer05>
great, so you can actually start
<ceene>
i'll talk to her now, maybe this afternoon we take a look at it all
<DocScrutinizer05>
I need to do some RL things, bbl. Please ask if there's anything unclear where I can help
<DocScrutinizer05>
many thanks!
<ceene>
cya!
<DocScrutinizer05>
don't worry about the lots of huge "TODO" in schematics, they are not as bad as they might look
<DocScrutinizer05>
it has the *final* power tree, not that of the stripped down proto_v2
goiken has quit [Ping timeout: 252 seconds]
goiken has joined #neo900
<DocScrutinizer05>
also important: keep in mind the whole pcbnew stuff that's there is only random and legacy, we need to keep a few component positions we already defined in proto_v1 but the rest is moot and you can start from scratch
<DocScrutinizer05>
I'm sorry I don't know what layouters are used to receive to work from, usually. I think I will delete all components from pcbnew except those which need to keep their positions - if that's ok with you
<DocScrutinizer05>
or should I "fix"/"lock" the ones that need to stay where they are, in components' properties?
<DocScrutinizer05>
anyway, really need to go AFK now, for a few hours
<gry>
enjoy
arcean has quit [Read error: Connection reset by peer]
<ceene>
DocScrutinizer05: if you can lock the components that have fixed known positions that'd be of enormous help
<ceene>
that's a major point of failure -a board that doesn't fit in the mechanic-
arcean has joined #neo900
goiken has quit [Ping timeout: 252 seconds]
<ceene>
usual thing to receive is the outline of the board - external and internal holes, etc