arcean_ has quit [Read error: Connection reset by peer]
timc1assic has joined #neo900
<timc1assic>
Weird. Booted up my new N900 and Ovi Maps seems to function. On my CSSU system it doesn't seem to have map data. Should I expect it to work?
che11 has quit [Ping timeout: 252 seconds]
norly has quit [Ping timeout: 252 seconds]
ob-sed has quit [Ping timeout: 240 seconds]
norly has joined #neo900
timc1assic has quit [Ping timeout: 240 seconds]
NIN101_ has joined #neo900
x29a has quit [Remote host closed the connection]
NIN101 has quit [Read error: Connection reset by peer]
x29a has joined #neo900
norly has quit [Quit: Leaving.]
ashneo76 has quit [Ping timeout: 246 seconds]
ashneo76 has joined #neo900
timc1assic has joined #neo900
webmeister_ has quit [Ping timeout: 250 seconds]
webmeister has joined #neo900
webmeister has quit [Ping timeout: 265 seconds]
webmeister has joined #neo900
webmeister has quit [Ping timeout: 265 seconds]
webmeister has joined #neo900
webmeister has quit [Max SendQ exceeded]
PeperPots____ has quit [Write error: Connection reset by peer]
webmeister has joined #neo900
PeperPots____ has joined #neo900
<DocScrutinizer05>
timclassic: depending on your eMMC aka VANILLA version your device may have local map data installed
<DocScrutinizer05>
iirc
<DocScrutinizer05>
but I think the Nokia map data server still supposed to work, so on CSSU you should be able to download the data needed when you're online. It will get cached locally so you need to download only once (and for updates)
<DocScrutinizer05>
also note that ovi maps afaik doesn't know to do on-board routing, for calculating any route you need online anyway
webmeister has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
check the alternative map apps (marble, mappero, etc), they can use alternative map data sets and some of them come with on-board routing and even guidance
<DocScrutinizer05>
maybe you can answer directly to internal ML?
<DocScrutinizer05>
it might reject or put on moderation your mail. Please report
<freemangordon>
DocScrutinizer05: also, it is possible to overwrite the sys_boot, by the so-called "Software Booting Configuration", see 26.4.4.4 in SWPU177AA (36xx TRM)
<freemangordon>
DocScrutinizer05: please you do it this time (the reply), I have to go afk for some time
<DocScrutinizer05>
yeah, maybe, but we'd want to load MLO from NAND anyway ;-)
<freemangordon>
yes, but for test...
<DocScrutinizer05>
ok I'll simply forward the irc log
<DocScrutinizer05>
any further notes before I send mail?
<freemangordon>
I guess Nik already knows that :)
<DocScrutinizer05>
I'm sure he does, but cooperatime engineering means we also state the obvious, just in case :-)
<DocScrutinizer05>
cooperative*
<DocScrutinizer05>
for example your link to the schem helped me a lot
<freemangordon>
the sys_boot is on the lower-right corner
<DocScrutinizer05>
found it :-)
<freemangordon>
BTW what revision is "our" BB?
<DocScrutinizer05>
we have a zoo of different version
Pali has joined #neo900
<freemangordon>
well, the 1GB one
<DocScrutinizer05>
I dunno the version of the particular one board
<DocScrutinizer05>
I'll add the question to mail
<freemangordon>
Pali: hi! Yes, all of the gadgets should have that __init removed
<freemangordon>
DocScrutinizer05: naah, it is not that important
<DocScrutinizer05>
but iteresting also for me
timc1assic has left #neo900 [#neo900]
<Pali>
I think that too!
<freemangordon>
Pali: I remember the last 2-3 monhs there were lots of crashing modules all over the kernel, because something was change in the __init semantics
<freemangordon>
*changed
<DocScrutinizer05>
that's 'nice'¡
<DocScrutinizer05>
ohmy, kernel devs
<DocScrutinizer05>
when they can't break something, they are not happy ;-)
<Pali>
this is again code maintained by mr. balbi
<freemangordon>
Pali: hmm, maybe the point is - bindxxx functions are not really called when the module is loaded, but on a later stage, when the core detects something matching (id?)
<freemangordon>
I guess he (along with the network guy) are our favorite kernel maintainers :)
<freemangordon>
anyway, I am afk for a while
<DocScrutinizer05>
((point is - bindxxx functions are not really called when the module is loaded)) [2015-02-07 Sat 23:16:21] <DocScrutinizer05> __init bind? maks no sense since you want to keep binding
<DocScrutinizer05>
freemangordon: enjoy your Sunday!
modem has joined #neo900
paulk-aldrin has joined #neo900
SylvieLorxu has joined #neo900
<DocScrutinizer05>
Pali: http://elinux.org/N900 for "Board snd-soc-rx51 Sound SoC Wiring" says "N/A" in first (doc) column. Shouldn't that rather be "<a href=...>N900 schematics</a>" ?
<DocScrutinizer05>
same for other stuff like "GPIO gpio-keys Proximity sensor"
<freemangordon>
there is no i2c0, it is just an alias for i2c1
<DocScrutinizer05>
freemangordon: ^^^ good, but rationale rather should be "a device name SHALL be in line with the name of the physical interface, as labeled in chip's TRM"
<freemangordon>
ok, why arguing with me?!? :)
<Pali>
freemangordon: was your alias patch accepted to mainline?
<DocScrutinizer05>
not arguing with you
<freemangordon>
Pali: no
<Pali>
ok, so we need it in -n900 tree
<freemangordon>
but it is not really needed
<Pali>
hm.. why?
<freemangordon>
the a8f3cb498f5b0436aa626e1dace15864b38f0baf does the trick without it
<Pali>
ok
<Pali>
then send a8f3cb498f5b0436aa626e1dace15864b38f0baf patch to ML :-)
<freemangordon>
ok
* freemangordon
needs to remember how :)
<Pali>
commit patch to git (add signed-off-by in commit message), then git format-patch HEAD^ and then git send-email file --to=... --cc=...
<freemangordon>
it is already signed by me, ain't?
<DocScrutinizer05>
assigning the I2C0 pins to second function in pinmux doesn't rename I2C1 in real life, so it shouldn't in linux as well
<Pali>
maybe there is TI userspace which numbers it from zero (i2c1 as 0)
<DocScrutinizer05>
hardly
<Pali>
I know that developers are very creative, so I bet there can be boards which userspace needs it...
<DocScrutinizer05>
it's kernel devel "booohooowaaa I *want* devices get numbered starting at #0. ALWAYS!!!"
<Pali>
hahaha, ubuntu except numbering from zero :-)
<Pali>
not one
<Pali>
expecting /dev/i2c-0
<DocScrutinizer05>
in HDA/SDA they invented naming by label because of their idiotic non-stable numbering concept
<Pali>
I think it is because kernel devices are numbered from zero (and not one)
<Pali>
and they want to have same numbering in all schemes
<Pali>
not mess
<DocScrutinizer05>
it's because kernel device devels want it started at 0
<DocScrutinizer05>
mess == device names not in line with TRM names
<Pali>
you can export device description
<Pali>
and write there correct name
<Pali>
I think that numbering of devices is not stable
<DocScrutinizer05>
such random numbering that has only one constant rule which is "pragma origin=0" is useful for a random set of absolutely equivalent devices *only*
<DocScrutinizer05>
I2C1 bus is NOT equivalent to I2C2 bus
<Pali>
anyway if you need to use i2c bus, you need to enumerate all i2c devices in /dev/ and choose those which you want to use (check name of i2c device, etc)
<Pali>
same is for disks
<Pali>
/dev/sda does not have to be always same disk
<Pali>
its up to udev to do some stable numbering (e.g. using permanent cache rules)
<Pali>
/etc/udev/rules.d/70-persistent-cd.rules
<Pali>
/etc/udev/rules.d/70-persistent-net.rules
<DocScrutinizer05>
as I told above. it's idiocy for SDA and there you actually _could_ swap attached drives. For I2C you _never_ have any option to swap
<Pali>
etc...
<DocScrutinizer05>
I2C is no pluggable interface
<DocScrutinizer05>
unlike SDA, USB, NET
<DocScrutinizer05>
...
<Pali>
yes, but that number is used only for userspace (if I understand correctly) and for entires in /dev/ is responsible userspace/udev
<DocScrutinizer05>
and unlike those, I2C is *very* low system level, other kernel drivers depend on it
<Pali>
kernel does not have to export stable names
<Pali>
other kernel drivers use DT description of devices, not kernel number!
<Pali>
DT is device tree, you put other i2c devices to correct node in that tree
<DocScrutinizer05>
well, the whole thing is again a fuckup done by kernel devels who got no clue about hardware, as usual
<DocScrutinizer05>
how the heck is userland supposed to know which I2C bus is the right one, when they don't get stable numbering from DT or kernel itself?
<Pali>
they check description of i2c bus... same as for non removable hard disks
<DocScrutinizer05>
digging up hw addr of I2C bus in the doomed corners of /sys ?
<Pali>
how would I know if that disk (hitachi) is /dev/sda? and not /dev/sdb?
<DocScrutinizer05>
that is NOT DT!
<Pali>
yes, but same problem for userspace applications
<DocScrutinizer05>
DT has NFC which drive is plugged to which SATA interface
<DocScrutinizer05>
for I2C there *are no* plugs involved
<DocScrutinizer05>
so I expect DT do it _right_
<DocScrutinizer05>
and name I2C devices same way they are named in schematics and TRM
<DocScrutinizer05>
just like SDA is SATA bus #1
<Pali>
yes dt can do it right, it can aslo set "device description"
<DocScrutinizer05>
(the first one) always. It's written on board
<DocScrutinizer05>
same way I2C1 is "written on board"
<Pali>
if somebody in TRM decide to choose string name "i2c1 - special device" for first device, then you can specify that string name in DT for correct device
<Pali>
but I would say, internal kernel numbering of devices starts from zero
<DocScrutinizer05>
so I expect I2C1 being one bus I can point at without checking any furhter, just like I can point to SDA SATA bus jack
<Pali>
and from userspace, you choose i2c device with string name "i2c1 - special device" like you see in TRM
<DocScrutinizer05>
well, as mentioned for sATA it's even less strict since those are pluggable
<DocScrutinizer05>
whatever sting name means
<Pali>
OT: in some context i2c is also pluggable... (display adapters HDMI/DVI)
<DocScrutinizer05>
err still not really
<Pali>
you can hotplug HDMI cable
<DocScrutinizer05>
it's invariably the HDMI I2C
<DocScrutinizer05>
and I'd wonder whom to kill if userland needs to find out which of I2C* is the one connected to the HDMI port
<Pali>
$ sudo i2cdetect -l
<DocScrutinizer05>
I look at schematics and see "aaah, that MUST be I2C-4" then use /dev/I2C-4 to access HDMI
<DocScrutinizer05>
dafaq! read big fat WARNING about I2Cdetect and similar stuff
<Pali>
its param '-l'
<Pali>
it just ask kernel for names
<DocScrutinizer05>
this definitely is NOT what userland is supposed to do, to find which /dev/i2c-* to use to talk to HDMI
<Pali>
-l is doing some find /sys and call ioctl which ask kernel for correct string name
<DocScrutinizer05>
honestly, kernel devels gone mad, or what?
<Pali>
you can ask for that name via /sys/class/i2c-dev/<dev>/name
<DocScrutinizer05>
again, that's NOT what userland is supposed to do
<Pali>
why? this is what is suppsed to do
<DocScrutinizer05>
ohmy
<Pali>
I have two graphics cards, each card has more ports (hdmi1, hdmi2, dvi, vga, ...) and each graphics card has more i2c busses...
<Pali>
only one card can assign number 1 to kernel
<DocScrutinizer05>
those ARE NOT IN DT!!!
<Pali>
you really should ask for kernel description of i2c busses
<Pali>
and not except some internal kernel numbering
<Pali>
there are other platform which do not use DT (eg. x86) and kernel cannot add special code for some platform (e.g arm) to provide other numbring in i2c subsystem
<Pali>
it will be big mess which is unmaintainable...
<DocScrutinizer05>
I don't want to check my device like transformers if it's currently configured as helicoper, boat, or jet, before I talk to the chip that's living on I2C#2 bus
<DocScrutinizer05>
and *always* will live on that very I2C bus, on same address
<Pali>
then you will ask kernel for i2c bus which has description "I2C#2 bus"
<Pali>
/dev/ is not stable and never it was (without udev)
<DocScrutinizer05>
bullshit, I will access /dev/i2c-2
<Pali>
is there any documentation which say that?
<DocScrutinizer05>
yes, 30 years of linux
<Pali>
read Documentation/i2c/dev-interface
<Pali>
"Each registered i2c adapter gets a number, counting from 0."
<DocScrutinizer05>
why the heck does kernel need to randomize stuff so userland needs to un-randomize it later on?
<Pali>
because drivers are loaded in ranom order (and asynchronous)
<Pali>
no, git tells me that this is since 2.6.12 (when linux moved to git)
<kerio>
lol
<DocScrutinizer05>
when a driver can't tell "ooh this is hw addr 0.0080, so this is bus #2 on OMAP", not even with help of DT, then this is fubar
<Pali>
if you want, I can search in full linux history when was numbering from 0 introducted
<Pali>
DocScrutinizer05: there are two different things: 1) internal kernel numbering (which is by definitions from zero) and 2) external string description of bus
<Pali>
and if you did not read i2c *kernel* API 10 years ago (since which this is stable) you did not used i2c API on linux correctly
<DocScrutinizer05>
meh, I got better things to do than to blame kernel devels for all the idiocy they introduced and continue to introduce. With every new kernel version. I already said they are not happy when thy can't break things, if onyl for stuff like "we changed pragma origin=1 to pragma origin=0 this time"
<Pali>
there is one thing, userspace API is not going to break
<DocScrutinizer05>
just devels implementing a idiotic rule 10 years ago doesn't make it right
<DocScrutinizer05>
yeah, and since /sys is NOT part of userland API...
<DocScrutinizer05>
good luck with all that shit
<kerio>
"it's not how i imagined it to work therefore it's bad"
<Pali>
full /sys not, but some parts yes!
<Pali>
bitkeeper tells me that numbering from zero is at least from 2002
<DocScrutinizer05>
numbering is worthless, no matter if from 0 or from 4711, when numbers are random anyway
<Pali>
"you have to decide which adapter you want to access. You should inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this."
<Pali>
this is what say API ^^^
<DocScrutinizer05>
now check changelog of /sys
<DocScrutinizer05>
brainfuck
<Pali>
/sys/class/i2c-dev/ is stable api
<DocScrutinizer05>
suuuure, since 20 years
<Pali>
did not you hear about Documentation/ABI/stable?
<Pali>
before blaming you should read kernel docs!
<DocScrutinizer05>
bye
<DocScrutinizer05>
when kernel docs are bullshit i don't need to read them before starting ranting
<Pali>
you did not read them, so you cannot say it is bullshit
<DocScrutinizer05>
I see the result
<DocScrutinizer05>
so it IS bullshit
<Pali>
result of what??? that you want to use internal kernel numbering and excepting that internal numbering will be always same and stable?
<DocScrutinizer05>
why the f*ck is *internal* kernel nubering showing up in /dev?
<Pali>
because some numbering must be used
<DocScrutinizer05>
sorry, I'm out. This is futile
<Pali>
also in output of ifconfig -a is used internal numbering
ashneo76 has joined #neo900
<ShadowJK>
So it's a bit like /dev/sd* numbering changing across reboots etc?
<Pali>
yes, because kernel does not have windows like registry where to store numbering
<DocScrutinizer05>
yes, obviously for *all* /dev/*
<ShadowJK>
My PC sometimes comes up with harddrives sda sdb sdc, sometimes sda sdf sdg
<Pali>
if you want stable /dev/ there is udev for it
<Wizzup>
systemd-udevd * ;-)
<DocScrutinizer05>
since... /dev is not a stable userland API. /sys is, partially
<DocScrutinizer05>
:-S
<Pali>
if you use stable netlink daemon (= old udev version on systemded), then you can have stable /dev/
<DocScrutinizer05>
/dev isn't since kernel likes to randomize stuff, just for fun
<Pali>
kernel just tell: new device with name NAME, id ID and description DESC was created
<Pali>
and netlink based daemon parse this message and create node in /dev/
<Pali>
its up to which userspace daemon will use for that
<Pali>
if DESC == "i2c bus number 2" ID == 0 SUBSYSTEM==I2C then its up to that daemon what will do
<Pali>
udev will probably create /dev/SUBSYSTEM-ID node
<DocScrutinizer05>
yeah, while kernel using $RANDOM for the name
<DocScrutinizer05>
excellent approach
<Pali>
DESC is what is sed by kernel driver or in DT (e.g that string from TRM), ID is first available
<Pali>
nobody force you to use systemd or *default* udev rules (which some userspace devs created)
<Pali>
you still do not see point? kernel tell you all information which you need (to userspace)
<Pali>
and its up to you what will you do with it (or what will your program with processing those information do)
<Pali>
kernel must solve also problems like: two different devices (card1 and card2) provides i2c busses and both cards have bussed with number 2...
<Pali>
i2c subsystem is generic for all platforms and must deal with this problem an all platforms
<DocScrutinizer05>
HUH?
<Pali>
(even on arm you can have 2 graphiscs cards)
<DocScrutinizer05>
s/i2c/usb/
<Pali>
and so devices are numbered internally (for historic reason from zero, not one) and its up to userspace daemon (e.g udev) if that number use for naming in /dev/ or not
<DocScrutinizer05>
I just wonder why kernel not simply creates /dev/device0000 to /dev/device9999 and completely hides all info that's already available to kernel drivers, like i2c bus number. after all some platform could have TWO fans or TWO power supplies or even 5 power switches
<DocScrutinizer05>
all the info would go to /sys so later on userland may find out what the heck is /dev/device4711
<Pali>
because it is created by userspace, not kernel :-)
<Pali>
ok, seems you totally did not understand it
<DocScrutinizer05>
what? /dev/ nodes are created by userland?
<Pali>
/dev/ nodes are created by userspace
<Pali>
/sys/ is exported by kernel
<Pali>
/proc/ by kernel too
<dos1>
(/dev/ nodes are created by userspace) unless you use devtmpfs
<Pali>
udev monitoring /sys (or waiting for messages from AF_NETLINK socket) and with information from rules it populates /dev/
<kerio>
dos1: rip devtmpfs ;-;
<DocScrutinizer05>
then what the fuck is the problem of DT with I2C numbering?
<Pali>
new versions of linux have devtmpfs pseudo FS, which automatically create devices in /dev/ by schme which was used by by some version of udev
<DocScrutinizer05>
why did it even change?
<DocScrutinizer05>
while maemo userland clearly NOT changed
<Pali>
maemo usersland incorrectly use /dev/i2c* devices
<DocScrutinizer05>
if what you say was 100% correct, the I2C names must not change by changing kernel
<Pali>
nokia hardcoded /dev/i2c* files instead checking bus description
<Pali>
and they hardcoded i2c device IDS into n900 board files as 1,2,3
<Pali>
and violated i2c documentation in kernel
<DocScrutinizer05>
yes, since that's a sane thing to do, since the hardware never chabges, so why not hardcode it?
<DocScrutinizer05>
changes*
arcean has joined #neo900
<ShadowJK>
And since the OS uses busybox, why bother testing scripts in bash :D
<Pali>
and because it was used for a long time, we do not want to break it... and because fix is very easy and *only* for n900, we can send patch for it
<Pali>
which does not introduce problems for other devices
<DocScrutinizer05>
ShadowJK: ...and dash and tcsh and csh and...
<DocScrutinizer05>
no way
<Pali>
"<DocScrutinizer05> yes, since that's a sane thing to do, since the hardware never chabges, so why not hardcode it?" because internal kernel i2c numbering has nothing with it
<Pali>
same as for network devices in network subsystem
<DocScrutinizer05>
if that would be true, who cares about kernel anyway?
<DocScrutinizer05>
fsck DT!
<Pali>
we, becase we have closed nokia apps which we would like to run
<DocScrutinizer05>
aha
<Pali>
and we cannot fix those nokia closed apps
<DocScrutinizer05>
aha
<DocScrutinizer05>
and that causes kenel to change device names how?
<DocScrutinizer05>
DT == 100% cruft
<Pali>
what caused changing internal kernel numbers? DT conversion...
<DocScrutinizer05>
DT == 100% cruft
<Pali>
it would be same, if you change DT code back to board code
<Pali>
DT is more easier to describe HW asn that board code...
<DocScrutinizer05>
yeah, of course¡ that's why we got wrong I2C names now
<Pali>
and before deleting board code from kernel permanently, we were asked to check and *report* regressions
<Pali>
so to minimalize problems
<Pali>
and one is also i2c numbering...
<Pali>
note that legacy board code for n900 was not removed yet!
<DocScrutinizer05>
"lemme introduce some DT cruft that does nothing to improve the system. Please check for regressions!"
<Pali>
nope, it improve this ARM mess situation
<DocScrutinizer05>
aha, yeah I see that clearly
<Pali>
legacy board code is one big mess in ARM
<DocScrutinizer05>
it worked
<Pali>
did you see it?
<DocScrutinizer05>
why would I even look at it?
<Pali>
to understand that board is is really worse then DT
<DocScrutinizer05>
you won't convince a dog about quality of dogfood by showing him the printing on label
<DocScrutinizer05>
it worked
<DocScrutinizer05>
so again, why would I look at it?
<DocScrutinizer05>
to understand why kernel devels feel like messing around with a new concept that THEY think THEY can understand more easily?
<Pali>
DocScrutinizer05: it worked but was not easy to extend that code
<Pali>
and do not rememember that we still have subsystems (like camera) which is not supported by upstream kernel yet
<Pali>
and one reason is that big mess in board code
<Pali>
DT is not new concept
<DocScrutinizer05>
no, reason is the mess in DT
<Pali>
its very old and now stable and used
<freemangordon>
Pali: "do not remember" == "do not forget"?
<Pali>
freemangordon: what?
<freemangordon>
(16,54,24) Pali: and do not rememember that we still have subsystems (like camera) which is not supported by upstream kernel yet
<Pali>
right, forget :D
<freemangordon>
:)
<DocScrutinizer05>
anyway, futile discussion
<DocScrutinizer05>
I think embedded best uses "momolithic" kernel, not general purpose kernel that also could run on a IBM3500
<DocScrutinizer05>
thus hardcoded I2C is exactly the thing I'd prefer
<freemangordon>
DocScrutinizer05: noone says the must be only one kernel that fits them all
<DocScrutinizer05>
while DT is 100% useless
<freemangordon>
*there
<DocScrutinizer05>
bbl
<freemangordon>
omap2plus config (for example) is not for production )and that is even admitted by the kernel devs)