<DocScrutinizer05>
some "nice" design goals like operating 5 light barriers from a 9V block battery for at least 12h
<wpwrak>
100% duty cycle ? :)
<DocScrutinizer05>
now that's a nobrainer, but 14 years ago that been kind of tricky
<wpwrak>
hehe ;-)
<DocScrutinizer05>
no 100%, more like 0.000000001%
<wpwrak>
well, if whatever crosses your barriers moves at relativistic speed, then duty cycle may still be a challenge today, but ... ;-)
<wpwrak>
(very low duty cycle) then 12 h sounds rather short
louisdk has quit [Remote host closed the connection]
<DocScrutinizer05>
I simply enabled the LED just until a light pulse got detected on photodiode
jake42 has quit [Ping timeout: 256 seconds]
Kabouik has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
added some max on time which exits to a event branch, plus a ultralow power sleep in MCU's mainloop, to throttle the whole thing to a 10Hz
<wpwrak>
sounds efficient, yes
<DocScrutinizer05>
we however had some troubles with bright sun, the mechanical design of the light path wasn't that good at filtering out sunlight from above
<wpwrak>
always trouble with those oversized thermonuclear lightbulbs :)
<DocScrutinizer05>
and to make things worse, all 5 photodiodes had to operate in parallel on only one of the available GPIO
che1 has joined #neo900
gurki has joined #neo900
che1 has quit [Remote host closed the connection]
<DocScrutinizer05>
worst design compromise been the 5V LDO however
<DocScrutinizer05>
that chip had all it needed, and was cheap, available, and a formfactor that guy of mausclick actually could handle
<DocScrutinizer05>
when I took over, he experimented by connecting conrad module kits (like "light barrier", "blinkenlight" (2 transistors ;-D) together, to achieve sth
wicket64 has joined #neo900
<wpwrak>
urgh ;-)
ReqGame has joined #neo900
<enyc>
DocScrutinizer05: ooh thats a good idea (about extended battery etc)
<enyc>
DocScrutinizer05: to hide extra gadgets under =)
jonwil has quit [Ping timeout: 244 seconds]
jonwil has joined #neo900
<DocScrutinizer05>
Oksana: SiLabs Si7020 looks so nice I might consider to try and find a good place for a footprint for that component. Will decide later then whether to populate it or not
<wpwrak>
looks like another "no liquids !" chip :)
<wpwrak>
(nice) Vdd(min) = 1.9 V. hrrmph.
<wpwrak>
and if we operate it at 3.3 V, it probably won't talk to our 1.8 V I2C
<DocScrutinizer05>
indeed, missed that
<DocScrutinizer05>
(Vdd/I2C)
<DocScrutinizer05>
the "no liquids" is allegedly dealt with by a protective cover or whatever
<DocScrutinizer05>
which is an option we need if we decide to use that chip (which won't happen thanks to 1V9)
<wpwrak>
yeah, looks fancy, that cover. keeps water out but lets humidity through. very nanotech ;-)
<DocScrutinizer05>
it's called goretex ;-)
<DocScrutinizer05>
hmm, usual 0.7/0.3*Vdd rating on I2C interface. I guess we could get away with that, even when operating the chip at 2V or 2V2
<DocScrutinizer05>
V(OL)(SDA) <0V6 but rather <0V4
<DocScrutinizer05>
we have several 2V8 and a 2V5 supply rail
<DocScrutinizer05>
~2V8 *0.7
<DocScrutinizer05>
~2.8 *0.7
<infobot>
1.96
<DocScrutinizer05>
ouch
<DocScrutinizer05>
wpwrak: what's been your verdict on level shifters?
<DocScrutinizer05>
generally
<DocScrutinizer05>
I seem to recall you mentioned some possible limitations on minimum allowable volatge difference between side A and side B?
<DocScrutinizer05>
in case of above sensor we could operate it at 3V3 or 2V8 and add a 2 level shifter FETs
<DocScrutinizer05>
(given we don't see I2C chip addr collisions)
<DocScrutinizer05>
7020 seems to be either 0x40 or 0x80
<DocScrutinizer05>
the chip needs to get placed exposed to "the outside" but must not collect dust, which is a sort of a paradox
<enyc>
;consieders saying somethig like Uarghghghhhhhhh Feature_Creep this will never get finished Uarghghghghhhhhhh =)
* enyc
considers saying something like Uarghghghhhhhhh Feature_Creep this will never get finished Uarghghghghhhhhhh =)
<DocScrutinizer05>
better you don't
<DocScrutinizer05>
the only thing that *might* slow down finsihing of this are those discussions
<DocScrutinizer05>
adding a chip is not slowing down any other development
<DocScrutinizer05>
it would, if done after we finished proto_v2 schematics, which we didn't yet
<Oksana>
Ok, Si7020. SHTC1 does not have a cover, and is overall strange (no digikey page, for one).
<DocScrutinizer05>
for now the only "slow down" I could see is an additional 30 min Nik would need to get the footprint and the component into the schematics and layout
wicket64 has quit [Remote host closed the connection]
wicket64 has joined #neo900
<DocScrutinizer05>
in a 2 weeks or so, the window for new chips like this cloeses somewhat. We got a complete schematics then, and those won't see many further changes unless absolutely needed
wicket64 has quit [Remote host closed the connection]
<DocScrutinizer05>
(complete schematics) for proto_v2 which is Neo900 sans core (aka CPU, PMIC, RAM, storage, etc)
wicket64 has joined #neo900
<enyc>
=)
* enyc
wonders how many protoctye boards are used for projects of this size/complexty/risk
<ds2>
DocScrutinzer: what PMIC are you settling on?
wicket64 has quit [Remote host closed the connection]
<DocScrutinizer05>
Nokia N900 has a stamp "2JH21" on PCB (in schematics photo it's ""JH20"). GTA04 needed some low one figure number of spins. In OM we had... dugh I don't wanna talk about that, but we still been better than what Nokia apparently did. For NeoN we hope for a 3 or 4 real prototypes (there been a board spin - v1 - which doesn't really count since it only was to move around some holes and never got pupulated with components)
<DocScrutinizer05>
ds2: TWL4030
wicket64 has joined #neo900
<enyc>
DocScrutinizer05: =))
<DocScrutinizer05>
enyc: the concept is based on the idea that PCBs are expensive, while our work is relatively cheap compared to it. So we try to eliminate *all* oopsies before we build a new prototype. And we do incremental prototypes which means we don't include stuff like CPU etc in proto_V2 so it can't ruin the complete board.
<DocScrutinizer05>
this approach is overall way cheaper but also much slower than the usual industry approach of doing many prototypes as fast as possible to find the bugs in schematics
<wpwrak>
(2JH21) without a 2JH19 or such, it could just be the 2.0 version :)
<DocScrutinizer05>
"much slower" not really applies to tiny projects like this one, where we don't have our own PCB fab to create a PCB in 3 days for us and after a week at max we could test the new proto hw. We need to wait like 2..3 months from "Go!" until we hold a proto in our hands
<wpwrak>
(level shifters) seems that they should be fine even if Vlow == Vhigh. not sure about frequency response, though. simulation failed me there, but we can always build prototypes ...
wicket64 has quit [Remote host closed the connection]
wicket64 has joined #neo900
mva has quit [Ping timeout: 256 seconds]
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
frequency response at least should be in the range of MHz
<DocScrutinizer05>
of course depending on FET used
mva has joined #neo900
<DocScrutinizer05>
wpwrak: what do you think about tentatively adding a Si7020? Plus level shifters
nox- has quit [Quit: Leaving]
<DocScrutinizer05>
maybe tagged "optional"
<wpwrak>
we can try ... seems small enough.
<DocScrutinizer05>
of course depending on us finding some good location to place that critter on PCB
<enyc>
sounds sensible =)
<DocScrutinizer05>
:-)
<enyc>
DocScrutinizer05: what other 'optional' feature requests have you been thinking about?
<wpwrak>
preferably next to something that gets really hot ;-)
<DocScrutinizer05>
hehe, no, iirc it has a builtin chip heater so we don't need external heating ;-P
wicket64 has quit [Remote host closed the connection]
wicket64 has joined #neo900
<DocScrutinizer05>
it seems there might actually some "sweet spot" for that critter: UPPER top, right upper corner exactly below the C-spring there
<DocScrutinizer05>
on N900 PCB tehere are some L-C filter components for right speaker, which we won't have in that location on NeoN board anyway
<DocScrutinizer05>
agree?
ReqGame has quit [Quit: Leaving]
<DocScrutinizer05>
the slider mech allows some "headroom" there (no nogo area like a few mm further to the left) and the chip has some "fresh air" there too
<DocScrutinizer05>
or was that heating on another one of the humidity sensors we checked today?
<DocScrutinizer05>
aaah "5.5 Heater"
<DocScrutinizer05>
>> The Si7020 contains an integrated resistive heating element that may be used to raise the temperature of the sensor. This element can be used to test the sensor, to drive off condensation, or to implement dew-point measurement...<<
* DocScrutinizer05
mumbles "heating, temperature sensor, air cooling... hmmmm"
<DocScrutinizer05>
seems this should also allow some sort of windspeed detection, though not very precise and rather slow
<Oksana>
That heater would not fry anything around here, I hope? It has 3.1 mA current, right?
<DocScrutinizer05>
when you know the "idle" temperature of the system, and you then apply a constant anount of energy to the temp sensor, it will heat up the slower/lesser the more wind is cooling it
mva has quit [Ping timeout: 272 seconds]
<Oksana>
It sounds like drafts inside a building :-) It's not like the sensor is designed to be exposed to outside wind (nasty thing, the wind is; brings sand and snow and salt water and what not).
<DocScrutinizer05>
obviously this is by design of case etc not suitable for measuring slow wind in the range of a few meter/s. And it's pretty slow until it can provide decent results. But for probing speed of e.g. a car or air velocity at exit of a fan by holding the device out of the window / in front of fan in an exactly defined orientation (screen facing down, so the wind can directly hit the upper right corner of device and go straigt through the gap
<DocScrutinizer05>
between display and kbd half) it might suffice
<DocScrutinizer05>
since we know hunidity and density (due to barometer) of the air, we can calculate quite well the temperature vs airspeed equation
<DocScrutinizer05>
Oksana: 3.1mA, right
<DocScrutinizer05>
anyway the temp sensor is 14bit and has an accuracy/noise of 0.01°C
<DocScrutinizer05>
which seems sufficient to pull off the above mentioned trick, even with a humbe ~10mW heating energy
<DocScrutinizer05>
s/accuracy/resolution/
<Oksana>
:-) IP67 is quite a good water-protection rating, for the cover of the chip.
mva has joined #neo900
<DocScrutinizer05>
accuracy is +-0.3°C
<DocScrutinizer05>
yep
<DocScrutinizer05>
and we solved the thermometer issue en passant
<DocScrutinizer05>
placing one of the other chips with accurate temp sensor (e.g. barometer) some cm away on same side of PCB like the humi even allows us to estimate amount of device internal stray heating the chip suffers from heat sources like CPU etc, by watching the temperature gradient on PCB
<DocScrutinizer05>
and operating the nearby speaker at low freq high amplitude might even create some forced ventilation ;-P
<DocScrutinizer05>
(just kidding, the last one)
* DocScrutinizer05
adds to BOM: 1 x Si7020, 1 x buffer capacitor, 2 x pullup R, 2 x levelshifter FAT
<DocScrutinizer05>
FET*
<DocScrutinizer05>
>> TGND Paddle This pad is connected to GND internally. This pad is the main thermal input to the on- chip temperature sensor. The paddle should be soldered to a floating pad.<< HMMMMM
<Oksana>
;-) That's why I sent this link, and not one of several others.
<DocScrutinizer05>
Oksana: thanks! Good job
<DocScrutinizer05>
I think a 3 usecases (humidity, airspeed, estimation of device internal energy dissipation in temperature domain) actually justifies getting this critter included
<DocScrutinizer05>
plus I doubt we could have done any similarly accurate ambient temp sensing with e.g. the barometer, particularly since that chip should rather get placed somewhere where it's less likely that is suffers from dust, the impossible raindrop, whatnot else
<Oksana>
And barometer would not be able to evaporate said impossible raindrop ;-) While Si7020 can :-)
<DocScrutinizer05>
indeed :-)
mva has quit [Ping timeout: 250 seconds]
<fling>
Hello. Any news? Where can I read some about the project status?
<fling>
but unfortunately I can't understand the voice and I can't recognize what is written there.
<DocScrutinizer05>
it seems the slides whould be public, so you don't need to read them in a videostream
<DocScrutinizer05>
should*
<fling>
Another question. I want to connect different hacking devices to neo900. What would be possible to connect to it via it's connectors?
<DocScrutinizer05>
we support a few general purpose IO and several power supply rails and USB on hackerbus. Up to you what you want to connect to that
<fling>
hmm hmmm
<DocScrutinizer05>
there's also UART with serves for console and IrDA/CIR
<DocScrutinizer05>
and you can re-assign several of those contacts by changing a few soldered "jumpers" on Neo900 PCB
<DocScrutinizer05>
e.g. for audio hacks
mva has joined #neo900
<fling>
DocScrutinizer05: Atleast I want a geiger counter and rf sweep.
wicket64 has quit [Remote host closed the connection]
<DocScrutinizer05>
well, I don't see any particular difficulties in connecting that stuff to hackerbus
<fling>
great :>
<DocScrutinizer05>
you just should make sure your design doesn't suck too much power constantly. Unless you're ok with rather short battery standby times
gypsy has joined #neo900
wicket64 has joined #neo900
wicket64 has quit [Remote host closed the connection]
<jonwil>
Inside my apartment it feels stuffy and humid
<fling>
jonwil: where are you at?
<jonwil>
Australia :)
<fling>
DocScrutinizer05: looks like it can be connected over serial.
<fling>
jonwil: I'm in Siberia. :>
<jonwil>
Wish you could send some of that snow my direction, I would much rather snow and cold than rain and super-humid
<jonwil>
its 85% humidity and 27c right now :(
<fling>
jonwil: I don't like humidity. It is killing lenses. Fungus starts to grow.
<fling>
lıʍuoɾ
<jonwil>
looks like the entire week is going to be more of the same (rain, max temps in the 30s or so and likely high humidity)
<jonwil>
It doesn't help that my apartment is un-air-conditioned (and no I cant afford to get one put in) and is made of solid bricks that seem to hold and retain heat like crazy :()
wicket64 has quit [Remote host closed the connection]
wicket has joined #neo900
ReqGame has joined #neo900
jonwil_ has joined #neo900
gypsy has quit [Quit: gypsy]
gypsy has joined #neo900
jonwil has quit [Ping timeout: 272 seconds]
jonwil_ is now known as jonwil
ashneo76 has quit [Ping timeout: 245 seconds]
<fling>
jonwil: what do you think about weather where you have -47°C temperature and 27mps wind speed together? :P
PeperPots_ has quit [Ping timeout: 250 seconds]
ashneo76 has joined #neo900
PeperPots_ has joined #neo900
wicket has quit [Quit: WeeChat 1.0.1]
jonwil has quit [Ping timeout: 245 seconds]
gypsy is now known as varu|zZz
jonwil has joined #neo900
ecloud has quit [Quit: No Ping reply in 180 seconds.]
ecloud has joined #neo900
ReqGame has quit [Remote host closed the connection]
ReqGame has joined #neo900
SylvieLorxu has joined #neo900
SylvieLorxu has quit [Client Quit]
ReqGame has quit [Ping timeout: 255 seconds]
jonwil has quit [Remote host closed the connection]
pigeons has quit [Ping timeout: 255 seconds]
pigeons has joined #neo900
pigeons is now known as Guest5457
jonwil has joined #neo900
ravelo has joined #neo900
arcean has joined #neo900
mvaenskae has joined #neo900
che1 has joined #neo900
sparetire_ has quit [Quit: sparetire_]
mvaenskae has quit [Ping timeout: 252 seconds]
gurki has quit [Ping timeout: 250 seconds]
jake42 has quit [Ping timeout: 245 seconds]
varu|zZz has quit [Quit: varu|zZz]
jake42 has joined #neo900
gurki has joined #neo900
jake42 has quit [Ping timeout: 245 seconds]
gurki has quit [Ping timeout: 250 seconds]
varu|zZz has joined #neo900
varu|zZz has quit [Client Quit]
varu|zZz has joined #neo900
kolp has joined #neo900
jake42 has joined #neo900
gurki has joined #neo900
jonwil has quit [Remote host closed the connection]
che1 has quit [Ping timeout: 252 seconds]
varu|zZz has quit [Quit: varu|zZz]
varu|zZz has joined #neo900
varu|zZz has quit [Client Quit]
varu|zZz has joined #neo900
che1 has joined #neo900
freemangordon_ has joined #neo900
Guest5457 is now known as pigeons
b1101 has joined #neo900
b1101 has quit [Client Quit]
mvaenskae has joined #neo900
b1101 has joined #neo900
phre4k has joined #neo900
<phre4k>
I just donated 111€ :)
<DocScrutinizer05>
ta
<DocScrutinizer05>
we msz have reached 400 meanwhile
<DocScrutinizer05>
must*
<DocScrutinizer05>
well, or will reach, soon
<DocScrutinizer05>
not special landmark, but nice
che1 has quit [Ping timeout: 245 seconds]
SylvieLorxu has joined #neo900
Pali has joined #neo900
freemangordon_ has quit [Quit: Leaving.]
che1 has joined #neo900
mvaenskae has quit [Ping timeout: 245 seconds]
che1 has quit [Ping timeout: 264 seconds]
che1 has joined #neo900
ravelo has quit [Quit: Page closed]
ReqGame has joined #neo900
b1101 has quit [Quit: b1101]
Pali has quit [Ping timeout: 265 seconds]
<freemangordon>
Pali: hi! Honestly, I think you should try to change your attitude on LKML ;). I know you're getting angry with some of the upstream devs, but making them angry too wouldn't help. also, what is the problem if we follow greg's idea to load NVS through sysfs?
<freemangordon>
dammit
Pali has joined #neo900
<freemangordon>
Pali: check the backscroll :)
<DocScrutinizer05>
huh? backscroll?
<phre4k>
it's like the elder scroll
<freemangordon>
hmm?
<phre4k>
only of IRC
<freemangordon>
DocScrutinizer05: wrong word?
<DocScrutinizer05>
freemangordon: why would Pali need to scroll to read 3 adjacent lines of IRC posts?
<bencoh>
because he just timedout/rejoined
<DocScrutinizer05>
actaully 2, of which one is "dammit"
<DocScrutinizer05>
aaah
<DocScrutinizer05>
I don't see that
<bencoh>
I know ;)
<freemangordon>
oh :)
<freemangordon>
fix your IRC client then :P
<DocScrutinizer05>
it *is* fixed to hide such noise :-D
<freemangordon>
yeah, yeah
<freemangordon>
and brought 15 more lines of noise ;)
<freemangordon>
the "fix" that is
<DocScrutinizer05>
that's why I need alarm from somebody else if a user spams chan with join-part loops
<Pali>
freemangordon: Marcel should change his attitude too!
<Pali>
he removed pavelm's bluetooth for n900 from linux tree
<Pali>
and now something totally irrelevant wrote to discussion
<freemangordon>
Pali: wait, what? isn't it in staging?
<freemangordon>
BT that is
<Pali>
no, it was removed
<freemangordon>
omg
<freemangordon>
I didn't see that on linux-omap ML
<Pali>
and I think he is that guy who broke userspace bluez (= no compatiblity with existing sw in bluez5)
<freemangordon>
but, but, why n900 BT was removed? do you have a link to LKML thread?
<bencoh>
oO
<Pali>
because Marcel forced Greg to remove it... reason: pavelm was not fast enough to fix everything in driver in time when Marcel wanted
<freemangordon>
I see
<Pali>
there was some long thread...
<DocScrutinizer05>
Marcel seems to be quite a jackass, when that's true
<freemangordon>
does pavel plan to send the driver again?
<Pali>
marcel want to see bluez on android again ^^^
<DocScrutinizer05>
wpwrak: do you think you might help with all this above?
<freemangordon>
Pali: hmm, it would've been good if you've cced me as well. Anyway, do you know if pavel needs some help with that?
<Pali>
I do not know... you can ask him?
<DocScrutinizer05>
wait, whom I quoted on my "BWAHAHAH" and "MUHAHA"?
<DocScrutinizer05>
Oh, Russel King
<DocScrutinizer05>
hehe, quote from TV: "based on those results, computer experts now write logarithms to automate that..."
<DocScrutinizer05>
almost as good as my favorite one: "this generator can provide 500 homes per year with electric power"
<DocScrutinizer05>
algorithm -> logarithm is what you get when neither you nor your spellchecker program have any clue what the whole thing is about
<bencoh>
:]
<DocScrutinizer05>
maybe the speelchecker could use a better logarithm ;-)
mvaenskae has joined #neo900
<DocScrutinizer05>
or TV could use moderators and comment off speakers and * with a brain, who actually use such brain to try and understand what they read and say
<freemangordon>
Pali: what about my qusetion re sysfs NVS interface?
<freemangordon>
*question
<Pali>
firmware here is correct place... because we have generic nvs files in linux-firmware tree
<Pali>
but for each n900 there is specific nvs data
<freemangordon>
yes, I know
<Pali>
and we want to use those specific nvs data and then fallback to firmware
<freemangordon>
my point is - what is the problem to load that unique data via sysfs?
<Pali>
dependency problem
<freemangordon>
as I can't find any problem
<Pali>
when to fallback to generic nvs data?
<Pali>
there can be race condition
<Pali>
how long could kernel wait for sysfs data?
<freemangordon>
wait, can't generic data be loaded and then unique data to overwrite it?
<freemangordon>
or in case unique data is loaded, generic to be ignored?
<freemangordon>
I see no race here
<freemangordon>
is it possible to load that unique data when the chip is up and running?
<DocScrutinizer05>
nvs==CAL ?
<freemangordon>
no
<Pali>
once you load data to wl chip, you can rewrite them, but you need to down interface
<freemangordon>
afaik
<Pali>
yes, NVS data are stored in CAL
<freemangordon>
hmm, ok
<Pali>
but not all
<Pali>
there is some bit for fcc and something other
<freemangordon>
and what is a problem if we bring the interface down for a second, load the unique data and bring it back up?
<freemangordon>
and how hard will be to implement calfs?
<freemangordon>
I mean - we have foss libcal, how hard is to implement the kernel part? any idea?
ReqGame has quit [Ping timeout: 255 seconds]
<DocScrutinizer05>
calfs?
<DocScrutinizer05>
you're honest?
<freemangordon>
hmm, thinking of it - that wouldn't really solve the problem, we don;t know when calfs is going to be mounted. though I guess kernel has tools to inform the drivers on fs mount
<freemangordon>
DocScrutinizer05: not sure I understand your question
<DocScrutinizer05>
I'm not sure what's calfs
<freemangordon>
CAL filesystem
<DocScrutinizer05>
you made that up, right?
<freemangordon>
the name? sure
<DocScrutinizer05>
you're aware that calfs has no hierarchy (aka folders/dirs), and has only a fixed very short maximum of file size allowed?
<freemangordon>
in one of the mails on linux-omap ML there is an idea to make a fs driver for CAL, so the data there to be accessible by the firmware loader. if I got that mail correctly
<freemangordon>
DocScrutinizer05: sure
<freemangordon>
remember who was the one to RE libcal ;)
<DocScrutinizer05>
given all that, why implement that stuff in kernel? wouldn't fuse do?
<freemangordon>
maybe
<freemangordon>
well, most probably
<freemangordon>
but isn't fuse huge?
<freemangordon>
never checked
<DocScrutinizer05>
I think it can't be so much huger than a *proper* kernel fs driver
<freemangordon>
there is also userspace part afaik
<freemangordon>
but yeah, that might work
<freemangordon>
Pali: what do you think? ^^^
<Pali>
yes, hard to implement in kernel (cal has non trivial structure and it should be correct in kernel mode) and problem is that NVS data are not in one cal struct
<Pali>
this is horrible hack to have it in kernel
<freemangordon>
but what about fuse?
<DocScrutinizer05>
fuse it! ;-)
<Pali>
stupid idea
<freemangordon>
:D
<DocScrutinizer05>
hahaha
<freemangordon>
you made my day :D:D:D
<Pali>
no, correct is: kernel ask usermode helper to provide data... usermode provide them or if not kernel fallback to direct firmware read
<DocScrutinizer05>
tbh CAL is a stupid idea ;-)
<Pali>
and userspace can do what wants
<Pali>
any stupid or less-stupid hacks
<freemangordon>
Pali: if I read between the lines correctly, upstream does does not want to depend on the userspace (read systemd)
<Pali>
what do you think, if any device manufator invent own storage mechanism... then it should go kernel?
<Pali>
systemd is one fucking SW
<DocScrutinizer05>
when I hear >>kernel ask usermode helper<< my toe nails roll up, might need some taming, those nails
<Pali>
and there are kernel developers who reject any depends on systemd
<freemangordon>
exactly
<freemangordon>
and now udev is part of systemd...
<Pali>
before direct firmware load was implemented in kernel, everything was done by usermode helper
<DocScrutinizer05>
isn't there a paradigm that says "kernel never waits for userspace"
<freemangordon>
sure, but it seems now this is no longer valid. See, I don;t believe we can fight and win with upstream, we'd better try to find a way that makes everyone happy, or something similar.
<freemangordon>
Pali: ^^^
<DocScrutinizer05>
when there's not, then this is a bug ;-P There should be
<Pali>
and there is paradigm "no regression"
<Pali>
and no userspace break
<DocScrutinizer05>
kernel MUST NOT wait for userspace to acknowledge or otherwise react on kernel. Kernel MUST NOT send requests to userland, only messages and signals
<DocScrutinizer05>
~2119
<infobot>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
<freemangordon>
Pali: still, could you elaborate on "fuse is a stupid idea"?
<DocScrutinizer05>
it's userland waiting for kernel, never the other wa round
<Pali>
because fuse itself is stupid
<Pali>
DocScrutinizer05: and what to do in case that driver needs firmware loading driver and firmware is not ready?
<freemangordon>
won't argue on that, but if it does the job in our case (WLAN and BT), why not?
<freemangordon>
Pali: defer loading?
<Pali>
and how long?
<freemangordon>
like all DT drivers do
<Pali>
sleep 1 && try_again?
<freemangordon>
until there is firmware
<Pali>
and if there is no userspace which load needed firmware or firmware is missing?
<DocScrutinizer05>
exactly
<Pali>
and what will fuse fix?
<Pali>
firmware needs to be in /lib/firmware
<DocScrutinizer05>
when there is no (response from) userland helper, kernel will wait forever
<Pali>
you cannot have your own fs in /lib/firmware because there is archive of linux-firmware
<freemangordon>
Pali: comeon, you know how deferred probe works
<freemangordon>
driver waits for nothing
<Pali>
yes, but deferred probe for DT or other drivers are used in case when they are waiting until kernel finish some job
<Pali>
which is expected to be ASAP
<Pali>
and it does not depends on userspace
<freemangordon>
exactly - in our case fuse to be loaded
<DocScrutinizer05>
(wait forever) that's exactly why I said "kernel MUST NOT wait on userland"
<Pali>
but userspace can do what wants
<Pali>
and also does not have to have firmware
<freemangordon>
wait, wait, my idea is:
<freemangordon>
defer the probe until there is what is needed in /lib/firmware/ti/
<DocScrutinizer05>
firmware loader in userland obviously needs to trigger some udev-alike mechanism on finish
<freemangordon>
or was it "ti-connectivity"?
<freemangordon>
it is still rough around the edges, but I think it can be polished
<Pali>
maybe, but now correct name is not important
<freemangordon>
yeah
<Pali>
but it still does fix our problem
<DocScrutinizer05>
does? or does not?
<Pali>
we have generic nvs data in /lib/firmware which can be loaded by direct kernel load option
<freemangordon>
ok
<Pali>
*does not
<DocScrutinizer05>
what generic data is that?
<Pali>
and we need to tell kernel (from userspace) to not use generic nvs data, but our (which will be generated on-the-fly)
<Pali>
NVS data
<DocScrutinizer05>
grrr
<freemangordon>
Pali: hmm, what about...
<DocScrutinizer05>
wlan doesn't need any NVS data
<Pali>
no, it needs them
<DocScrutinizer05>
wlan needs a MCU frimware
<Pali>
wl1251 needs NVS and firmware
<freemangordon>
DocScrutinizer05: those are some calibrations
<DocScrutinizer05>
and how could calibration data be generic?
<freemangordon>
averages?
<DocScrutinizer05>
tzzz
<freemangordon>
(for example)
<DocScrutinizer05>
broken by design
<freemangordon>
anyway, this is the design
<DocScrutinizer05>
if the data is soooo generic, it gets hardcoded into kernel driver
<DocScrutinizer05>
as default values
<phre4k>
lol, after lurking just 2 days in this channel I already like the dev community. I hope that damn phone sparkles my programming senses again, else I'll stay a lousy admin for the rest of my life :D
<freemangordon>
DocScrutinizer05: that's irrelevant, we search for the way to load the unique data, not generic one
<DocScrutinizer05>
no way ever it belongs into /lib/firmware/*
<DocScrutinizer05>
the unique data belongs into /lib/firmware/
<freemangordon>
DocScrutinizer05: the problem is that it is in CAL
<DocScrutinizer05>
or maybe /lib/local/firmware ? ;-D
<DocScrutinizer05>
freemangordon: yeah, got as much about the problem
<DocScrutinizer05>
how do other hw platforms solve this?
<freemangordon>
no idea, not sure the other platforms have such kind of a problem at all
<DocScrutinizer05>
tbh I'd bindmount our CAL data over /kib/firmware/foobar, using fuse
<freemangordon>
that wouldn;t solve the problem
<DocScrutinizer05>
why not?
<freemangordon>
you need that mounted by the time the driver wants to load the firmware
<DocScrutinizer05>
yes, obviously
<freemangordon>
and nothing assures you have it
<DocScrutinizer05>
why not?
<freemangordon>
because you can have wlan driver complied in the kernel, for example
<DocScrutinizer05>
isn't there any dependency handling in kernel drivers?
<DocScrutinizer05>
beyond mere open() etc?
<freemangordon>
no, the tool we have is "defer probe". And what is the dependency in our case?
<DocScrutinizer05>
I think modprobe aliases and whatnot could do the job
<DocScrutinizer05>
modprobe and udev are prolly your friends
<freemangordon>
"-EPROBE_DEFER"
<freemangordon>
modprobe does not play role with built-in drivers
<DocScrutinizer05>
o.O
<DocScrutinizer05>
sorry?
<DocScrutinizer05>
you won't tell me wl125x driver is monolithic?
<freemangordon>
if you built wlan driver not as a .ko file, but as a part of zImage
<freemangordon>
nothing stops you from doing that AFAIK
<freemangordon>
Pali: correct?
<DocScrutinizer05>
a zImage has hardcoded priorities
<DocScrutinizer05>
you *know* in which sequence your monolithic drivers get initialized
<freemangordon>
don;t think so, with DT boot it is a bit different
<Pali>
"<DocScrutinizer05> if the data is soooo generic, it gets hardcoded into kernel driver" --> driver is GPLv2 which is incompatible... linux-firmware.git tree is for those data and there are already
<DocScrutinizer05>
please don't ask me for a technically correct solution for a GPL problem
<DocScrutinizer05>
;-P
<Pali>
you can compile what you want into zImage
<freemangordon>
DocScrutinizer05: no, you don;t know the order, that's why there is deferred probe
<DocScrutinizer05>
exactly
<Pali>
basically any data are not part of drivers
<DocScrutinizer05>
freemangordon: that's broken by design then
<Pali>
they are in external firmware files
<Pali>
and linux-firmware.git is for that
<freemangordon>
DocScrutinizer05: broken or not, that's it afaik
<freemangordon>
at least with DT
<Pali>
init sequence is not defined
<Pali>
of drivers
<freemangordon>
:nod:
<DocScrutinizer05>
well, there's no solution to the problem "how do I load firmware data from a file in /foo/bar/latemount/xyz during init of a monolithic kernel driver that might happen before mounting *any* filesystem (except / )
<freemangordon>
there is - deferred probe
<DocScrutinizer05>
no, there is only one: systemd
<DocScrutinizer05>
;-P
<freemangordon>
you ask the kernel to re-probe driver loading until all the needed pieces are in place
<freemangordon>
"kernel" == "driver loader"
<freemangordon>
or however it is called
<DocScrutinizer05>
deferred probe can give you deadlock, e.g. when /foo/bar/latemount/xyz is a remote volume that's mounted via NFS over WLAN
<freemangordon>
no deadlock here, you just don;t have your wlan working
<freemangordon>
also, the next time the probe function is called, is when another module gets loaded successfuly
trx has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
you should be able to see the bigger picture - when there's one layering issue, it's highly likely that there will be arbitrary number of more or less similar ones with the concept
<freemangordon>
Pali: hmm, can't we add that data in DT? runtime generated?
<freemangordon>
(no fuse :P)
<DocScrutinizer05>
wtf?
<Pali>
no, we cannot
<Pali>
DT is parsed immediatelly after kernel is booted
<Pali>
that *hack* for adding hw revision and cmdline is done *before* kernel bootsd
<freemangordon>
sure, but you can add/remove nodes whenever you want, afaik
<DocScrutinizer05>
the whole design is fubar
<freemangordon>
or not?
<DocScrutinizer05>
DT my ass
<Pali>
there can be race condition even if it is possible
<Pali>
DocScrutinizer05: DT is really good idea
che1 has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
DT is a god solution to a problem we don't have
<DocScrutinizer05>
good even
<Pali>
DT is static description of connected HW
<Pali>
and you *need* to know at which i2c address is connected bq chip
<Pali>
and DT describe it
<DocScrutinizer05>
exactly, and why do we need that? we need a platform specific image anyway. It's not like we could run an image made for e.g. beagleboard or pandora
<Pali>
at one place (in one text file!) you have description of HW
<freemangordon>
DocScrutinizer05: that's the idea
<freemangordon>
one image ro rule them all :P
<freemangordon>
*to
<DocScrutinizer05>
DT is made to deal with minor differences in supposedly compatible platforms, read: x86 ISA PC
<Pali>
DocScrutinizer05: somewhere you need to write at which address is connected bq chip
<Pali>
where you want to store this platform-dependent information?
<DocScrutinizer05>
DT is completely incapable to turn a pandora image into something that runs on a Neo900
<Pali>
bq driver is wrong place
sparetire_ has joined #neo900
<freemangordon>
anyway, arguing over if DT is good idea or not won;t solve the problem with wl1251 NVS
<DocScrutinizer05>
in my book there's no bq driver, since that's only a chip and no DT can tell the circuit it's used in
<freemangordon>
DocScrutinizer05: lets not waste time on that, DT is where the kernel is moving. period.
<DocScrutinizer05>
the abstraction level of DT is 3 levels/magnitudes too low
<DocScrutinizer05>
freemangordon: good luck with that
<Pali>
I'm against any calfs, specific sysfs node for nvs data or something similar which can lead to race condition...
<freemangordon>
why luck? n900 already boots with DT, I guess Neo900 won;t have problems either
<Pali>
it you think something else, write to that kernel discussion
<DocScrutinizer05>
freemangordon: need a hint? Integrate pspice into kernel, so you have a decent format to base your DT on
<Pali>
because finding arguments here in irc log is really hard
<freemangordon>
Pali: trust me, I got your point.
<freemangordon>
I really wanted to discuss as we may come with some solution at the end
<DocScrutinizer05>
deferred_probe is da shite
<DocScrutinizer05>
highway to race condition hell, during kernel init
<Pali>
btw, there are other drivers in kernel which needs to load firmware from userspace helper
<Pali>
1. dell_rbu (or how it is called) for upgrading bios
<freemangordon>
how's that solved there?
<freemangordon>
oh, I guess it is static data only
<DocScrutinizer05>
if you need firmware for a chip, make the kernel driver load it and place the file into /boot/firmware
<freemangordon>
no fs access from drivers :P
<DocScrutinizer05>
since /boot/ is where kernel lives
<freemangordon>
iirc the API to do that was removed
<Pali>
2. leds-lp5523 (led program is laoded via request_firmware)
<DocScrutinizer05>
freemangordon: so what? then add it again
<freemangordon>
won;t happen, it will be rejected
<DocScrutinizer05>
Pali: WUT?? LP5523 is loading program for LEDs during driver init?? I don't think so
<Pali>
no
<Pali>
but you can program that led
<Pali>
and it is done via legacy /sys/ (which mce do) or with new request_firmware interface
<DocScrutinizer05>
LED patterns are no firmware
<Pali>
TI thinks something else
<Pali>
they deprecated that sysfs interface
<DocScrutinizer05>
fuck TI then
<freemangordon>
I guess "they" == "upstream"
<Pali>
in this case TI == upstream
<DocScrutinizer05>
I don't think so, the lp5523 driver is written by Nokia and it's basically crap
<Pali>
and now is maintained by TI people
<DocScrutinizer05>
who got no idea what LP5523 *is*
<DocScrutinizer05>
sysfs node deprecated? fine!!! move lp5523 to /dev/lp5523/mem
<freemangordon>
hmm, can we rmmod built-in driver?
<DocScrutinizer05>
NB I got NFC about that stuff, so take it with a grain of salt
<DocScrutinizer05>
I seem to recal paul fertser was very upset/puzzled why N900 kernel can't unbind the usb driver
<Pali>
DocScrutinizer05: sysfs node for lp5523 will be there
<Pali>
it will not be removed
<Pali>
at least, TI revered all those patches
<Pali>
and never tried it again when I wrote that our /usr/sbin/mce use it and patches broke userspace app
<Pali>
just new interface (via request_firmware) is preferred
<Pali>
but old must work too
<freemangordon>
Pali: do we need a new NVS if we chage fcc rules?
<Pali>
yes
<freemangordon>
ok. (replying to dan's mail)
<Pali>
I replied
<Pali>
but you can too :-)
<DocScrutinizer05>
folks, I need to run. cya and keep the kernel tidy ;-)
<Pali>
DocScrutinizer05: do you know ACPI? :-)
<DocScrutinizer05>
not a single bit
<freemangordon>
ok
<Pali>
do you want to see ACPI or DT in arm world?
<Pali>
:D
<Pali>
(ACPI needs to have in kernel special virtual machine)
<DocScrutinizer05>
neither, since we don't have such type of hw platform that could describe minor differences to other platforms in any of both. They both are cruft for embedded
<Pali>
DT describe HW. you then compile & load modules which you need for that HW
<DocScrutinizer05>
and to me it seems kernel devs have nfc about embedded
<Pali>
and DT also provide init data (like number of i2c buses ans so)
<DocScrutinizer05>
meh, forget it
<DocScrutinizer05>
DT is no hardware description language. Use pspice as I suggested before
lexik|m has joined #neo900
<DocScrutinizer05>
see H-E-N, when DT could do what it's supposed to, then we wouldn't need a kernel hack to make N900 do USB-host, right?
<freemangordon>
Pali: what marcel says makes lots of sense
<Pali>
yes
<Pali>
I'm writing responce
<freemangordon>
with the only issue there is no such API right now :D
<freemangordon>
ok
<wpwrak>
DocScrutinizer05: (driver fixing) seems that they already know what to do and the feedback is rather clear and specific. not much point in getting involved.
<freemangordon>
wpwrak: they?
<wpwrak>
freemangordon: the author and whoever may work with him
<wpwrak>
the way i read it is that marcel said "clean up this mess. here are the (mostly simple) changes i want: ...". then nothing happened for over half a year. then he got angry.
freemangordon1 has joined #neo900
freemangordon has quit [Read error: No route to host]
freemangordon1 has quit [Client Quit]
freemangordon has joined #neo900
<Pali>
wpwrak: pavelm told me that are other messy drivers in staging which were not removed and pavelm's bluetooth had better state... and it was removed
<Pali>
btw when I sent 1 line patch for fixing another staging driver (buffer overflow) it took about half of year until greg included it into kernel
<Pali>
but for revoving pavelm's driver greg was too fast
b1101 has joined #neo900
mvaenskae has quit [Ping timeout: 255 seconds]
che11 has joined #neo900
<wpwrak>
pity we don't have a fair process committee that collects all the submissions, then develops a consensus-based review report and democratically votes on a balanced schedule. maybe something like ITU, with government-appointed experts on due process and appropriate protocol ;-)
phre4k has quit [Ping timeout: 240 seconds]
b1101 has quit [Quit: b1101]
<Pali>
freemangordon: read mail, pavelm now bisected commit which broke bluetooth driver
<jonwil>
specifically the changes it makes to the NVS after reading the NVS from CAL
<jonwil>
the stock binary asked CSD for some info that it used to calculate the regulatory domain, my clone pulls that info from CAL (i.e. hardcoded) but is otherwise the same.
<Pali>
ok
<jonwil>
so factor that in when deciding how it should all be done...
<freemangordon>
Pali: what is the problem with gpl3? I can change it
<Pali>
I still think that it is imposible to implement it correctly in kernel
<Pali>
freemangordon: do you have cal parser library?
<freemangordon>
Pali: I know what calvaria is, my question was more like "what, you don't know libcal"?
<freemangordon>
yes
<freemangordon>
so what?
obsed has joined #neo900
<Pali>
do not remember about clone of libcal
<freemangordon>
oh :)
<freemangordon>
LGPL2
<freemangordon>
that should be ok for the kernel
<Pali>
ok, so this will not be problem
<freemangordon>
I can change the license to whatever is needed
<Pali>
so you can send link to source that we have library with compatible license now
<Pali>
you can ask if they accept that code into kernel :D
<freemangordon>
hehe
<freemangordon>
accept as what?
<Pali>
no idea...
<freemangordon>
Pali: still, I don;t get it how having sysfs iface is different to what nokia does on the stock kernel
<Pali>
nokia interface was rejected for upstream
<freemangordon>
I mean from a functional POV
<Pali>
and with sysfs you can do same think
<freemangordon>
exactly
<Pali>
no difference
<freemangordon>
why not do it like that then?
<Pali>
I think that only greg wrote his opinion which will be rejected by network mainatainers
<freemangordon>
well, we can at least ask them, correct?
<Pali>
yes
<Pali>
send that nokia's patch again :D
<freemangordon>
oh
<freemangordon>
comeon, I am talking about sysfs
<freemangordon>
not that nokia socket(or whatever it was)
<freemangordon>
netlink?
<Pali>
yes, netlink
<Pali>
I sent patch which can set mac address via /sys and it was rejected
<Pali>
so I bet nvs data via /sys will be rejected too
<Pali>
also patch for bt coex via /sys was rejected
<Pali>
I really think that sysfs idea is just greg opinion
<freemangordon>
hmm, is there a way to inform kernel that something has changed in the userspace?
<Pali>
nothing which will be accepted by network team...
<Pali>
yes
<freemangordon>
lets use it then
<Pali>
netlink and uevent
<freemangordon>
overwrite /lib/firmware.../nvs and inform the kernel
<Pali>
I really do not want to store device specific nvs data in rootfs
<freemangordon>
bindmount it dammit :(
<Pali>
one file?
<freemangordon>
yes
<freemangordon>
or the whole dir if you wish
<Pali>
it is possible to bindmount one file?
<Pali>
I think only directory is possible
<freemangordon>
DocScrutinizer05: is it possible to bindmount a file?
* freemangordon
asks google
<freemangordon>
Pali: we can always copy the needed files in /tmp/something and bindmount /lib/firmware/ti-connectivity
<freemangordon>
I know, I know, not the best solution, but should make upstream devs happy
<Pali>
and is not this again really stupid hack?
<freemangordon>
it is
<freemangordon>
what is the alternative?
<Pali>
I would like to hear what is bad on my approach to add new kernel function which will first try to use usermode helper and then direct load
<Pali>
now there are two functions: one which do that but in different order and another one which is using only direct load
<freemangordon>
those guys don;t want to depend on user mode firmware loadre, iiuc
<Pali>
usermode loader will not be removed from kernel
<Pali>
I do not belive that it will be accepted by other devs & Linus
<freemangordon>
ok, but do we have usermode loader in systemd? don;t tell me if it is good or bad, please :) .
<Pali>
in which version?
<Pali>
in older yes, in current not
<freemangordon>
current ofc
<Pali>
but kernel must work also without systemd
<Pali>
this change will not be accepted
<freemangordon>
Pali: I am not sure you get my point - what I saw so far on the lkml thread is that most devs will be happy with userspace helper creating NVS file and informing kernel to reload it. Everything else was rejected more or less
<freemangordon>
lets do it that way and move on :)
<freemangordon>
otherwise someone should write a whole new framework for dynamic FW loading
<Pali>
I will wait for other responces from other developers...
<freemangordon>
ok
<Oksana>
Why is systemd mentioned? It's not going to be included in Fremantle, is it? [Sorry for not understanding most of the discussion]
<freemangordon>
Oksana: what about if you want another distro?
<Oksana>
That's ok, just do not depend on something. If it happens to work with systemd, that's fine; but it's responsibility of systemd to support 'everything' and get bloated, not our responsibility to support 'unusual' ways of thinking. It would be like supporting Word's Docx format because Word cannot handle MathML, or something.
<Oksana>
Sorry for distracting you with noise. Feel free to get back to discussing kernel, usermode loader, and making sure that kernel does not wait for usermode to find needed data in CAL.
Oxyd76 has quit [Write error: Connection reset by peer]