<DocScrutinizer05>
Oksana: if you want. I simply don't take care anymore about that domain
<DocScrutinizer05>
which prolly means I will forget to discontinue it when next annual fees are due
<DocScrutinizer05>
then I'll frown two days and forget for another year, it's only 10 bucks
modem has quit [Ping timeout: 256 seconds]
arcean has joined #neo900
<DocScrutinizer05>
anyway what I won't do is discontinuing the domain without prior warning
<DocScrutinizer05>
so yes, I would appreciate when somebody else takes over but only when I don't have too much hassle with the transfer
<DocScrutinizer05>
ooh and re "let's see what techstaff says"... AIUI techstaff is mainly doing maintenance for servers, NOT any highly maemo specific "development" (maybe except for the autobuilder maintainer). Anyway asking our *sysops* about stuff like duplicate dirs in rmo is not exactly what they like to invest any of their precious time into. Particularly since *everybody* can compare subdirs in rmo and check if there are duplicates
<kerio>
everybody?
<kerio>
everybody with an account, maybe
<DocScrutinizer05>
close enough
<DocScrutinizer05>
though, why would you need an account to check anything of rmo details?
<kerio>
also, i guess that "there's a bunch of static files with lots of duplicates, how do we reduce the used space" is the sort of stuff you'd ask a unix sysadmin
<kerio>
DocScrutinizer05: the alternative is to download every file to check for duplication
<kerio>
and you can't know if something's a symlink through the web server
<DocScrutinizer05>
kerio: ((there's a bunch of static files with lots of duplicates)) yes, exactly. AS SOON as you can list those files with full name
<DocScrutinizer05>
a "I heard some rant that there MIGHT be..." won't fly
<DocScrutinizer05>
which is exactly my point
<DocScrutinizer05>
several people looked into it a year or two ago, and we sanitized parts of that mess. Most likely not all though
<DocScrutinizer05>
fun part: some dirs that formerly were symlinks now diverged when updates to e.g. fremantle-1.3 didn't implicitly sync to fremantle anymore
<kerio>
well, as a first thing you can do rdfind -makehardlinks
<DocScrutinizer05>
no
<kerio>
why not ;-;
<DocScrutinizer05>
a) we don't use hardlinks
<kerio>
well, as a first thing you can do rdfind -makesymlinks
<DocScrutinizer05>
and b) we need to check each single symlink manually
<kerio>
the .debs are static files
<kerio>
aren't they
<DocScrutinizer05>
since some stuff is explicitly NOT meant to be a link
<DocScrutinizer05>
see fremantle, fremantle-1.2, fremantle-1.3
<kerio>
those are directories
Pali has joined #neo900
<DocScrutinizer05>
you need to use common sense and experence and historic knowledge to decide what's a symlink and what is explicitly NOT a symlink
<kerio>
not for files that will explicitly not change
<kerio>
because they're referred to by name + hash in Packages
<kerio>
but a rose by any other name would have the same md5
<DocScrutinizer05>
in this case I can tell you fremantle-1.2 is supposed to stay static while fremantle gets updates which are possibly not compatible to 1.2 and those updates will propagate to fremantle-1.3 which is supposed to be a symlink to fremantle
<kerio>
the updates will be put in **new files**
<kerio>
dude
<kerio>
are you serious
<DocScrutinizer05>
yes
sparetire has quit [Quit: sparetire]
<DocScrutinizer05>
rethink!
<DocScrutinizer05>
eventually you'll grok it
<DocScrutinizer05>
fremantle-13 is a symlink to fremantle. fremantle-1.2 is NOT
<kerio>
WHO GIVES A SHIT
<kerio>
I'M SYMLINKING DEBS
<bencoh>
(regarding rep.m.o) maybe just a dump of "find ." would do :)
<DocScrutinizer05>
so what? that'S the reason why you are not one of techstaff
<DocScrutinizer05>
*probably* originally fremantle was a collection of symlinks to fremantle-1.2, and new packages replaced a symlink by a real file in fremantle, while fremantle-1.3 was a dir symlink to fremantle
<kerio>
will any existing .deb file be written to?
<DocScrutinizer05>
no, the yget deleted and replaced by new version
<kerio>
then you can replace them with symlinks or hardlinks to dedup them
<kerio>
without actually affecting anything
<DocScrutinizer05>
ORLY?!
<kerio>
YARLY
<kerio>
if you don't approve the vaguely crude solution, that's fine
<kerio>
but don't tell me that it wouldn't work
<DocScrutinizer05>
I told you every simgle problem needs manual solution, not automatic symlinking
<bencoh>
DocScrutinizer05: does it mean that we dont have the fremantle-1.2-compatible packages anymore ?
<bencoh>
or did I just misunderstand what you said ?
<kerio>
fremantle-1.2 and fremantle-1.3 are still there
<DocScrutinizer05>
bencoh: I forgot the status. But it's more likely that we got too many data than too few
<bencoh>
hmm
<kerio>
fremantle without any suffix was pointing to -1.2, now it points, or it should point, to -1.3
<bencoh>
a mix of 1.2 and 1.3 in 1.2 repo ?
<DocScrutinizer05>
bencoh: I forgot the status.
<kerio>
1.2 is fine, the issue is that fremantle and fremantle-1.3 should be the same but they're copies
<bencoh>
okay, nevermind :)
<kerio>
or something like that
<kerio>
anyway, too much data, rather than too little
<bencoh>
kerio: that's what I thought at first, but ...
<DocScrutinizer05>
and yes, fremantle and fremantle-1.3 desynced
<bencoh>
hmmm
<bencoh>
and which one is the most up to date ?
<kerio>
we'll just pretend that fremantle without any suffix is cssu-specific
<kerio>
problem solved
<kerio>
bencoh: i don't think it's a thing
<bencoh>
(well, looks like extras/fremantle-1.3 is up to date, at least)
Openbot has joined #neo900
<kerio>
i bet there's scripts that refer to fremantle and scripts that refer to fremantle-1.3 running around
<DocScrutinizer05>
yes, particularly in autobuilder we had that problem. We fixed it to get autobuilder to work again
<Openbot>
Ah checking this conversations plugin thing
<DocScrutinizer05>
openbot: "Hi! " or "morning!" is the correct greeting, not "ping"
<kerio>
DocScrutinizer05: SYN
<bencoh>
kerio: ACK (mitm)
<Openbot>
Ok
<Openbot>
anyway it works
<kerio>
it would be problematic, if not for the fact that you fail at tcp ._.
<kerio>
RST
<bencoh>
huhu
<bencoh>
true
<kerio>
you forgot syn
<bencoh>
yeah I know :)
<Openbot>
Docscrutinizer05 your brain seems supercharged after the toothache..
<DocScrutinizer05>
(dup files) anyway an hour of sysop work is worth some 50 bucks at least, even when done voluntarily. A 1TB server HDD is ~ 100 bucks
<bencoh>
DocScrutinizer05: to be honest, my only question regarding this is "what should we mirror if we wanted to"
<Openbot>
Is that work that scary ?
<kerio>
tru dat
<DocScrutinizer05>
bencoh: THAT is a *very* good question
<kerio>
bencoh: download.maemo.nokia.com
<bencoh>
kerio: I already mirror this one (at least the "critical" part)
<bencoh>
apps, mr0, 002
<kerio>
hey wtf
<bencoh>
(yeah, 002 is not critical)
<kerio>
cellmo-icpr82-headers_0.1.2009.12.1+0m5_armel.deb is a 404
<Openbot>
kerio i figure you downloaded the whole freemantle repo so is it possible to cd it and send to me ?
<kerio>
openbot: you come off as really rude, overall
<kerio>
so i'm not going to do that
<kerio>
no seriously, wtf is cellmo-headers
<kerio>
and why is it a 404
<Openbot>
well pls point what was rude @kerio as thats how i may figure out what was wrong :)
<bencoh>
kerio: where does that come from ?
<Openbot>
We download from repos and you downloaded a repo isint that diffrent lol
<kerio>
bencoh: downloads.maemo.nokia.com
<bencoh>
I see cellmo-icpr82-headers_0.1.2009.47.2+0m5_armel.deb
<bencoh>
and cellmo-headers_8.2.2010.08-1+0m5_all.deb
<DocScrutinizer05>
Nokia never implemented _strong_ protection of their "sign in to access' stuff
<bencoh>
still lI dont understand why it's on rmo, but meh :)
<kerio>
mostly because nobody outside of n900 owners would actually care
<bencoh>
(and not on download.nokia)
<DocScrutinizer05>
always been a silly "protection by obfuscation"
<DocScrutinizer05>
bencoh: prolly download.nokia.com was an afterthought, or temporarily been just a mirror of the stage on m.o evidently
<DocScrutinizer05>
(at least for tabletsdev)
<bencoh>
hmm, maybe
<DocScrutinizer05>
and Nokia implemented all that staging pretty sloppily, in a sense of lack of authentication the content servers had to do to download from stage
<DocScrutinizer05>
thus everybody could as well use stage instead of nokia.com CDS
<DocScrutinizer05>
and when they took down tabletsdev.nokia.com "due to security threats" or whatever, they simply stopped stage on m.o ;-P
<kerio>
Pali: do you know how to verify that the files in a repository pool have the correct hash, given a Packages file
<DocScrutinizer05>
and went all nuts when maemo sysops started it again
<kerio>
?
<DocScrutinizer05>
they forgot to stop the CDS infra X-P
<DocScrutinizer05>
even wose, Nokia bashed *us* to pirate their content
<DocScrutinizer05>
and actually they thought we hijacked the nokia.com domain - BWAHAHAHA
<DocScrutinizer05>
Imean, running a content distribution system server farm on Akamai and paying for it each month without using it is bad enough. But then bashing maemo techstaff for hijacking "Nokia.com" URL when we simply started stage on m.o again and that server farm happily resumed operation... PATHETIC
<bencoh>
DocScrutinizer05: :))
<bencoh>
kerio: md5sum
<bencoh>
(or sha, or whatever)
<kerio>
i don't think md5sum can parse a Packages file
<bencoh>
oh you mean an automated way ?
<DocScrutinizer05>
somebody did
<DocScrutinizer05>
years ago
<DocScrutinizer05>
when we had that hashsum error issue
<DocScrutinizer05>
due to borked autobuilder (related to the symlink resp NFS issue)
<DocScrutinizer05>
ask merlin1991 maybe
<DocScrutinizer05>
or xes
<DocScrutinizer05>
I think those two guys checked each single deb hash
<bencoh>
looks like reprepro can do that
<kerio>
Description: <insert up to 60 chars description>
<kerio>
legit, ovi repo
<kerio>
legit
<DocScrutinizer05>
*I* would simply recreate the unique repo hashsum/signature file locally, then diff
<DocScrutinizer05>
which prolly also is what the guys did back when
arcean has quit [Ping timeout: 246 seconds]
<DocScrutinizer05>
then they "only" had to kcik out the false positives for packages that actually got updated
<DocScrutinizer05>
which been the major part of the issue
gurki has joined #neo900
<DocScrutinizer05>
anyway, afk. Heard there's a thing called RL. Some call it "the big blue box"
<DocScrutinizer05>
on sidenote: about to order/receive another 5 samples of a 1GB PoP, this time cryptically labeled "* TNO"
<bencoh>
hmm
<DocScrutinizer05>
if they look good, I may want to get another 1000 of them
<bencoh>
:D
<bencoh>
for how much ?
<Openbot>
Great!
<DocScrutinizer05>
we'll see
<DocScrutinizer05>
I'm not reporting about particular expense since otherwise I'd start a never ending arguing what's needed, what's too expensive and why some stuff cost us 1000s and we got garbage for and who's paying for such mishap
<Openbot>
Is t
<Openbot>
hat 64 gb emmc is also comptiable wirth 900 out of the box
<DocScrutinizer05>
in the end it's a package expense to get stuff done. Some is expense with no return, other stuff works out, we need to average
<DocScrutinizer05>
openbot: yes
<DocScrutinizer05>
bencoh: when I tell you now "the chops cost 20ct each, but we spent 10000 to bribe the guy who gave them to us..." - what would you say (NB this is a made up example)
<DocScrutinizer05>
s/chops/chips/
<bencoh>
DocScrutinizer05: :-)
<Openbot>
can you give me part no name maybe i find it offline :)
<bencoh>
I guess I'd say "meh >_>"
<DocScrutinizer05>
exactly :-)
<DocScrutinizer05>
that's why I won't answer such questions
<Openbot>
Docscrutinizer05 ^
<DocScrutinizer05>
openbot: we had that issue checked and evaluated for ~1 year now
<DocScrutinizer05>
you find "RAM" in upper left corner
<Openbot>
Err okay
Openbot has left #neo900 [#neo900]
<merlin1991>
and he's gone, err wat?
<DocScrutinizer05>
openbot.... usual
<DocScrutinizer05>
hi merlin1991 :-)
<bencoh>
:)
<DocScrutinizer05>
merlin1991: maybe you can answer kerio's question about how to hashsum-check debs?
<kerio>
already done
<DocScrutinizer05>
ooh
<bencoh>
DocScrutinizer05: on one of the chan you dont want to hear about ;)
<bencoh>
+s
<DocScrutinizer05>
yeah, better that, it's slightly OT here anyway
<DocScrutinizer05>
and I'm "wasting" time on maemo related stuff that's not really related to Neo900
<DocScrutinizer05>
bad habits
<DocScrutinizer05>
and an incapability to keep focused
<DocScrutinizer05>
on my side
<DocScrutinizer05>
soon win7mac will /join and then the project is at peril because I got no minute/day to work on Neo900
<bencoh>
:D
<DocScrutinizer05>
I understand and tolerate when people ask in this channel about history of maemo. where else they could anyway, when they want _me_ to answer. Recent stuff however is clearly OT
<DocScrutinizer05>
doesn't mean I myself always notice when crossing the line. see above
<P-G>
For what it's worth, I'm more interested in running the Debian build if that's an option.
<P-G>
Maemo may be more specialized but I'm not familiar with it or Nokia's software in general.
<DocScrutinizer05>
P-G: you're free to run whatever you like. The concept of Neo900 is that we just provide all the needed info (incl POC drivers for specific peripherals) and you find or build the OS of your choice
<P-G>
Sounds good to me. :)
<DocScrutinizer05>
Neo900 UG is not doing software development beyond what's commonly known as Board Support Package
<DocScrutinizer05>
maemo as well as replicant and debian and whatnot is a 100% community project. On purpose
<DocScrutinizer05>
this way we make sure no closed blobs will ever exist and no dependency on goodwill of Neo900 UG will spoil your user experience, even years into the future
<P-G>
Yeah, I think that's important. Phones need to go open source.
<P-G>
I guess they already are to some extent but I use Motorolla's Android...
<P-G>
The world looks very grey to me. :(
<DocScrutinizer05>
android RIL is commonly frequently closed source vlob
<DocScrutinizer05>
blob even
<P-G>
I'm just not comfortable enough with phone tech and linux to risk damaging my phone. I should probably buy another to experiment on but I don't even know what OS are out there.
<DocScrutinizer05>
and more often than not you see more closed stuff on android phnes, otherwise stuff like the skunkworks android releases (forgot the name) wouldn't be needed
<P-G>
I have a lot of issues with my current OS. Not customizable at all.
<DocScrutinizer05>
sheeeeeet I forget more and more stuff. what's that "rooted android" name? (*not* replicant)
<P-G>
I don't remember either, lol. I did some research a while back but it was all very confusing. :(
<DocScrutinizer05>
kerio: au secours!
<kerio>
?
<DocScrutinizer05>
"rooted android"?
<DocScrutinizer05>
THE alternative android version
<kerio>
cyanogenmod?
<DocScrutinizer05>
YES!!!
<FIQ>
?
<FIQ>
ah
<DocScrutinizer05>
I always thought it was "something blue*" ;-D
<FIQ>
hnvm
<FIQ>
-h
<kerio>
P-G: neo900 is designed with n900 compatibility in mind, kinda
<P-G>
Yeah, I understand. I'm just looking for a good phone though. :p
<DocScrutinizer05>
not "kinda" :-)
<FIQ>
what are you looking for in particular
<kerio>
DocScrutinizer05: i won't be able to flash the latest n900 COMBINED fiasco and have it work
<DocScrutinizer05>
P-G: Neo900 *is* a good phone no matter if you use maemo or any other OS on it
<kerio>
so if n900 compatibility was the goal, you guys failed
<kerio>
:>
<DocScrutinizer05>
kerio: how do you know?
<P-G>
Doc: That's why I'm here. :D
<kerio>
DocScrutinizer05: because i strongly doubt that nokia's flasher-3.5 will support the neo900
<DocScrutinizer05>
hah!
<kerio>
if it does, hey
<kerio>
that's neat
<DocScrutinizer05>
the question rather is if NOLO will work on Neo900, which I kinda doubt, without patches
<kerio>
the neo900 has like 3 design guidelines, i guess
<bencoh>
kerio: I wouldn't be so sure about it not working
<bencoh>
kerio: there are some crazy people around here ;p
<DocScrutinizer05>
but maybe we come up with a patched xLoader that allows NOLO to work, or we provide a patched NOLO
<kerio>
1) make it reasonably easy to port fremantle on it, 2) modem is actively hostile, 3) let's not waste all the R&D that went onto the GTA04
<kerio>
at least, that's what i understood
<DocScrutinizer05>
so you could flash rootfs but not NOLO. For obvious reasons you also cannot flash cmt with flasher-3.5
<bencoh>
kerio: p.ali reversed most of the protocol with 0xffff, so ....
<bencoh>
I suspect Doc might end up willing to rewrite a compat loader :>
<kerio>
oh, and from what i got from this channel, 4) let's keep the /sbin/preinit shit so bootmenu still installs nicely
<DocScrutinizer05>
4) is a moot point since it's not in Neo900 UG responsibility
<kerio>
i heard that DocScrutinizer05 personally coded a check in ROMBOOT that mounts all the partitions and checks for the existance of /sbin/preinit, and fails to boot if there's none
<DocScrutinizer05>
1.1) "port maemo" is according to post#1 #2 in FPTF tmo thread
<kerio>
also, how can we inspect ROMBOOT to see if there's no backdoors in it?
<DocScrutinizer05>
ROMBOOT is 32k iirc
<kerio>
with it being read-only, i don't know if we have to trust it more or trust it less
<DocScrutinizer05>
and it actually is READ(-only) afaik
<DocScrutinizer05>
I guess you simply can memdump it and then disassemble the file
<DocScrutinizer05>
freemangordon: ^^^ ???
<P-G>
Kerio: It's kind of hard to explain what I want since I'm so picky but if the Neo900 were fully functional I would buy two or three right now. I am pretty happy with the functionality of modern Motorolla phones, like the Droid/Razr series, but the designs are lacking in a bunch of ways (e.g. FLOSS software support, no hardware security, poorly placed audio jacks). Kind of a half-assed answer
<P-G>
but basically I want a phone I can trust to be secure, reliable, and generally well designed.
<DocScrutinizer05>
Pali: ??
<kerio>
the first one is a given
<kerio>
well
<kerio>
will be a given
<kerio>
i guess the "default" will be fremantle
<FIQ>
I thought the default would be some minimal debian-esque just to verify that stuff works?
<DocScrutinizer05>
kerio: how do we know it's a Cortex-A8 and not some secret design that only pretends to be A8
<P-G>
"In January 2015, it was reported that Microsoft is investing in Cyanogen..."
<DocScrutinizer05>
OUCH
<P-G>
That's just embarassing.
<bencoh>
that's ... "lol" :)
<DocScrutinizer05>
kerio: generally you _never_ can be sure about chip level backdoors. then OTOH a chip level backdoor is extremely difficult to implement and use, since... well it's chip level. What exactly would you want to do to exploit/activate it? and what shall the backdoor do when activated?
<bencoh>
"12:41 < P-G> Kerio: It's kind of hard to explain what I want since I'm so picky" dont worry, I'm pretty sure there are people as picky as you are here
<FIQ>
I don't see how that is a terrible thing @ <P-G> "In January 2015, it was reported that Microsoft is investing in Cyanogen..."
<FIQ>
<
<P-G>
Lol, probably. I think we have the same taste though. ;)
<FIQ>
MS seem to in general be a bit more liberal towards FOSS nowdays
<DocScrutinizer05>
only thing such chip level backdoor could do was privilege escalation on detecting a certain magic trigger
<P-G>
I don't actually mind if Cyanogen incorporates and ercieves money from Microsoft but it is a bit suspiscious.
<P-G>
Like Google closing code on Android.
<DocScrutinizer05>
but the rest of what to do needs to get coded on file level, IOW the backdoor is just a priv esc vuln that a malware could use
<DocScrutinizer05>
you invariably need to load and execute the malware
<bencoh>
P-G: cyanogen isnt "opensource" anyway
<P-G>
Yeah, I suppose that's true. Pretty much nothing is... I would still like to give Cyanogen a try just because I think it supports Google's apps market. That would be convenient. I know it's possible to lock down permissions and kill Google's background services.
<bencoh>
most of it is plain "AOSP" but each image ("ROM" as they call it) is full of blobs
<bencoh>
P-G: replicant is opensource
<DocScrutinizer05>
kerio: (load and execute) OK, in theory the backdoor daemon could check all data written to RAM for the magic trigger and then execute the appended data. Thus you could embedd such malware code into arbitrary data files, not only executables
<bencoh>
they dont ship blobs
<bencoh>
and they have a few (2~3 iirc) devices in a mostly working state with full OSS
<DocScrutinizer05>
kerio: but that's highly unlikely since it a) creates lots of overhead on CPU and b) the lower the overhead the higher the risk that the backdor gets activated by mere coincidence
<P-G>
Bencoh: Google apps market support? Actual app/service permissions?
<bencoh>
hmm ?
<P-G>
Replicant.
<bencoh>
I dont think you're willing to use google market when you install replicant
<bencoh>
I'd rather use fdroid "market" ;)
<P-G>
I like the idea of apps, I just don't like the way they're managed.
<bencoh>
but I dunno, I dont see any reason why it wouldnt work
<P-G>
Fdriod?
<bencoh>
and you can still grab binaries from the google-free apk "mirrors"
<bencoh>
(now we're definitely offtopic)
<P-G>
Lol, sorry. :p
<DocScrutinizer05>
kerio: and note that such backdoor would be on ALL chips of that release at least, no matter what the device and what the OS. So any exploit would first need to find out about the perticular environment it's running in, and then act massively different on that result
arcean has joined #neo900
che11 has joined #neo900
<DocScrutinizer05>
after all you want to run the malware on the tablet, not on the router that's connecting the tablet to the internet. Or vice versa. Invariably you need to tailor your malware to the very particular target platform so it uses the actually available peripherals which you don't know how to easily detect since you neither know the particular OS before you probed for it.
<DocScrutinizer05>
chip level backdoors are theoretically feasible (and "known" to have been used in at least one instance on iirc microVAXen) but terribly hard to implement when you don't know each and every detail of the target platform the chip will get used in
<kerio>
microVAX had a chip-level backdoor? :o
<DocScrutinizer05>
either microVAX or DECstation
<DocScrutinizer05>
err, wasn't that the same? ;-)
<P-G>
What sort of front-end application would be used to handle phone calls and text messaging in Debian? SIP client?
<DocScrutinizer05>
no idea
<P-G>
Would that be like client --> SIP loopback --> hardware API --> GSM or whatever?
<P-G>
Hm.
<DocScrutinizer05>
rather not, looks overly complicated
<P-G>
Yeah but it wouldn't be good to make a custom application.
<DocScrutinizer05>
GSM is not SIP, no similarity on any level
<P-G>
SIP would just be the language the application speaks to the API.
<P-G>
Since we aren't making the applications, the API would need to read that.
<DocScrutinizer05>
you need a rather platform specific audio setup, and a tool that sends some AT commands to the control tty of modem
<DocScrutinizer05>
and no, SIP protocol is quite different to AT commands needed to generate or tear down calls and particularly manage registration state in cell modem
<bencoh>
and the audio setup can be a "standard" audio routing system plus a custom plugin
<P-G>
Yeah, I think that's the driver layer?
<DocScrutinizer05>
for Neo900 I hope to see cmt audoio getting implemented as 100% standard conforming ALSA audio card
<DocScrutinizer05>
since that's what it actually is
<P-G>
Yeah, that would be nice.
<P-G>
Not sure why it isn't already like that. :(
<P-G>
Confusing stuff.
<DocScrutinizer05>
because of BB5 modem being really braindamaged on how audio works
<P-G>
Ugh.
<DocScrutinizer05>
audio on BB5 actually is rather like SIP resp actually RTP
<P-G>
Well, SIP is basically the only technology that needs a softphone.
<DocScrutinizer05>
BB% connected to linux as phonet0 network device, and audio gets streamed over that network in a certain channel similar to ports on tcp/ip
<DocScrutinizer05>
BB5 that is
<Pali>
and how it is working with usb modems?
<DocScrutinizer05>
usb modems usually have no voice
<Pali>
option sell mini pci-e cards (usb based) which have also voice support
<DocScrutinizer05>
one rare device has a built in USB audiocard
<DocScrutinizer05>
anyway our modem doesn't have that, it comes with very simple plain PCM
<DocScrutinizer05>
basically identical to the codec
<DocScrutinizer05>
alas we went away from option since it has no matching formfactor
<bencoh>
"basically identical to the codec" ?
<P-G>
So Maemo would interface its applications directly with BB5 and Debian would use something like loopback from a SIP application and translate that to BB5 on the driver layer?
<Pali>
this is gsm mini pci-e card (usefull for laptops) which have voice support, not only data
<Pali>
and is usb based
<DocScrutinizer05>
bencoh: N900
<bencoh>
oh
<DocScrutinizer05>
P-G: how's SIP related to audio?
<P-G>
Well, it's not really. I'm just trying to figure out how people are using Debian to manage calls and messaging. We aren't building a custom front-end application to interface with BB5, are we?
<DocScrutinizer05>
SIP establishes a session that *may* use RTP and some codec and that codec samples input from a audio source and plays back inbound voice to a audio sink
<DocScrutinizer05>
we're not interested in BB5
<P-G>
Debian doesn't have phone/sms apps, does it? Only SIP clients.
<DocScrutinizer05>
*shrug*
<P-G>
I've got numbers to press!
<bencoh>
P-G: you're only referring to the UI
<bencoh>
well, afaict
<DocScrutinizer05>
using a SIP app to establish cmt calls sounds like using a c compiler to format a harddisk
<bencoh>
P-G: basically you want a dialer, right ?
<P-G>
Yeah, and messaging app. I can't imagine how they would work in Debian.
<bencoh>
and some "custom" protocols support as well
<P-G>
Ok, AT. I know I've heard of that somewhere before. :p
<bencoh>
hayes ;)
<DocScrutinizer05>
dos1 adapted SHR dialer to already initiate and accept phone calls on our protoV1 which had nothing but modem module on a PCB, attached to PC via USB
<P-G>
Yeah, I'm reading about this now. I've heard of it before but I totally forgot. :p
<P-G>
I don't know much about phones.
<P-G>
Or really anything.
<DocScrutinizer05>
*usually* you want a middleware like fso or ofono to talk to the modem, but that's more of a software design and system architecture concern than a technical requirement
<DocScrutinizer05>
such middleware takes care about sending the right AT commands in the right sequence at the right time
<bencoh>
and prepare the audio routing ... sometimes
<DocScrutinizer05>
and dos1 patches fso to handle our modem of Neo900
<DocScrutinizer05>
patched*
<P-G>
Software service compartmentalization is nice.
<P-G>
Thanks Dos1. :D
<DocScrutinizer05>
he ran the debian with fso middleware and SHR dialer on PC and connected our modem via USB, just like it will be connected to the device's linux later on
<P-G>
I might want to try that sometime just to learn how AT works. This is all very exciting for me.
<DocScrutinizer05>
and he sent and received SMS and initiated and received voice calls, just no audio since audio not even connected to PC on that protoV1
<DocScrutinizer05>
P-G: on N900 you can use pnatd to talk AT to modem
<DocScrutinizer05>
it even works ;-)
<DocScrutinizer05>
...for some AT commands
<P-G>
Lol, that's pretty awesome.
<P-G>
So the modem translates AT to GSM (except in asia)?
<DocScrutinizer05>
on Neo900 modem yes. On N900 it's pnatd that translates to that gibberish the modem talks
<DocScrutinizer05>
called ISI
<P-G>
Man it's hard to find details on this stuff.
<DocScrutinizer05>
did I mention that N900 BB5 modem wasn't really made for the usecase it's used for in N900?
<P-G>
Hm...
<DocScrutinizer05>
BB5 is a complete phone on a chip, meant to run Symbian or whatever *on modem*. NOT to talk to a linux system
<drathir>
but n900 have good speed...
<DocScrutinizer05>
that's why some stuff is really awkward on BB5
<drathir>
ofc not mention about power comsumption;p
<P-G>
But you aren't using BB5 anymore?
<DocScrutinizer05>
no, we use P*S8 Cinterion
<DocScrutinizer05>
which is a WAY better modem
<DocScrutinizer05>
actually family of modems
<P-G>
I'll take your word for it. ;)
<drathir>
DocScrutinizer05: in connection to linux how will be detected?
<DocScrutinizer05>
and even better: it's actually *available*
<P-G>
Lol.
<DocScrutinizer05>
drathir: please rephrase
<drathir>
DocScrutinizer05: i mean when connected by usb to linux pc the device how will be recognised?
<DocScrutinizer05>
on Neo900 you want to make sure that the particular USB bus won't allow any other devices on it than the modem, so modem cannot pretend to be a keyboard for example
<drathir>
thats good i guess for setups the linux pc based internet connection access...
<drathir>
there will be also possibility on the fly change connection type, eg. mass storage mode/modem mode/or that dont like but mtp mode?
<DocScrutinizer05>
modem USB is completely unrealted to device USB available for user
<drathir>
that wass will be great is ability to boot from neo900... some kind of cdrom/pendrive mode...
<DocScrutinizer05>
I *think* you can do this on N900 already (and some N900 users actually did it)
<P-G>
So P*S8 models are just L and X?
<DocScrutinizer05>
in mass storage mode the device should act exactly like a USB memstick
<DocScrutinizer05>
PLS8 PHS8 PXS8
<DocScrutinizer05>
we won't support the PLS8-* variants
<P-G>
Looks like there's a V and G too... They have this stuff spaced out in a weird way.
<drathir>
bc with that big amount of storage i guess developers like to have complete os able to run on any pc...
<drathir>
DocScrutinizer05: thats good news...
<P-G>
Oh, V and G are LGA mounting.
<DocScrutinizer05>
err sorry
<DocScrutinizer05>
we won't support the PHS8-* variants
<DocScrutinizer05>
we WILL support both PLS8-* variants
<P-G>
Ok. The V model doesn't look good anyway.
<P-G>
So it's L or X?
<DocScrutinizer05>
L H X
<P-G>
H says it's LGA mounting. Is that not an issue?
<DocScrutinizer05>
H as reduced featureset cheaper variant of X
<bencoh>
"on Neo900 you want to make sure that the particular USB bus won't allow any other devices on it than the modem, so modem cannot pretend to be a keyboard for example"
<bencoh>
how will you do that ? kernel hack ?
<DocScrutinizer05>
err, yes prolly sth like that. Or is that udev?
<bencoh>
prolly not udev
<DocScrutinizer05>
somebody needs to know which kernel module to load after a USB pluggable device identified itself
<bencoh>
yeah, but you want it not to be able to talk at all
<bencoh>
what if HID drivers are already loaded, or builtin ?
<DocScrutinizer05>
you can't forbid enum otherwise you don't know if it's allowed "to talk"
<DocScrutinizer05>
but honestly that's not my domain of expertise
<DocScrutinizer05>
ask the kernel cracks, like Pali
<bencoh>
hmmm looks like udev does export something to tell the kernel to "blacklist" a specific usb device
<DocScrutinizer05>
I just specify "you probably don't want to allow any other device than ttyUSB on that particular USB bus"
<DocScrutinizer05>
up to system devels how to implement that then
<bencoh>
right :)
<DocScrutinizer05>
on a sidenote: I might be about to secure a 500 complete mech part kits for Neo900 (aka N900 to revamp)
<DocScrutinizer05>
we _need_ to start a fund raiser for that expense
<DocScrutinizer05>
everybody who "donated" 100EUR didn't contribute to securing mech parts, and so far that wasn't an issue since some customers may not want any
<DocScrutinizer05>
(the ones who want a NeoN board to upgrade their own N900)
<DocScrutinizer05>
we need a ~150EUR from all those who want a complete Neo900 device incl LCD and case and all
<DocScrutinizer05>
an *additional* 150EUR
<DocScrutinizer05>
the exact price will get calculated on purchase, and of course excess payments are taken into account for the final amount to pay
<DocScrutinizer05>
I think that's great news when it actually pans out
<DocScrutinizer05>
you can purchase a N900 in disassembled and QA checked condition, and we will eventually retrofit/upgrade your N900 with a NeoN biord before we send it to you
<DocScrutinizer05>
board
<DocScrutinizer05>
eventually we'll need another 100..150EUR from *all* Neo customers for purchasing risk electronic components like the 1GB RAM PoP chips, domesheets, RGB LEDs, etc pp
<DocScrutinizer05>
so in other words, we will start sales soon
<DocScrutinizer05>
hope you like those news. I do
<kerio>
i don't really like those news, i don't have money to spend right now ._.
<DocScrutinizer05>
well, we can cope with a certain very small amount of late preorders
<DocScrutinizer05>
and you got at least one month before sales even start
<DocScrutinizer05>
when too many don't want or can't support the preorders of components and mech kits, we will have to roll back the whole thing and decalre Neo900 dead
<DocScrutinizer05>
or postpone until it died from oblivion
<drathir>
DocScrutinizer05: any link to twitter to rt?
<DocScrutinizer05>
500 mech kits a ~150EUR is 75k. We only have a 20some k left in our kitty
<DocScrutinizer05>
drathir: sorry?
<bencoh>
which reminds me .... I still havent "donated"/applied for a device
<DocScrutinizer05>
...and those 20k are for R&D
<drathir>
or is more like private info?
<DocScrutinizer05>
this is more like "private info2 for now, we need to officially announce stuff soonish however
freemangordon_ has quit [Quit: Leaving.]
<drathir>
oh thats fine, bc i guess a lot of ppl make happy that announce when public out...
<bencoh>
DocScrutinizer05: are the "donate" info up to date ?
<DocScrutinizer05>
bencoh: please consider above reasoning already, when doing your "donation"
<DocScrutinizer05>
minimum for NeoN board: 250 total. Add 150 when you want a complete device incl case,LCD, all
<bencoh>
I gathered that :)
<DocScrutinizer05>
of those all but the initial 100 are "refundable" in a sense that you purchase real physical stuff with it and you can ask for shipping that stuff to you
<DocScrutinizer05>
please don't ask for invoice during next 6 weeks at least :-)
<bencoh>
good luck with the inventory :>
<DocScrutinizer05>
it takes a while till we sorted that out
<P-G>
MySQL to the rescue?
<DocScrutinizer05>
oooh, please don't get that wrong: when you ask for Neo900 shipping stuff to you, that stuff will never again enter the manufacturing line
<bencoh>
dont worry, I wont anyway ;)
<DocScrutinizer05>
to be utterly clear on that: Neo900 UG doesn't accept N900 parts or electronic components sent in by customers to build a Neo900 from it
<bencoh>
I really dont feel like soldering everything together ... it's fun and all, but meh :)
<P-G>
Have people actually been doing that?
<bencoh>
and I dont feel like asking for parts just to send them back
<DocScrutinizer05>
P-G: no, not really, not yet. Some asked for sending in their N900 to have the upgrade done by us. We ponder if and how we can offer this, but probably we can't
<DocScrutinizer05>
international shipping is a b*tch, and doing it twice is prolly not worth it
<DocScrutinizer05>
also much headache with warranty, aka "the device was OK when I sent it to Neo900 UG"
<P-G>
Yeah, I don't think it's worth the trouble. You could post an upgrade tutorial eventually maybe.
<DocScrutinizer05>
of course we will provide very fine upgrade tutorial
<DocScrutinizer05>
that's never been a question
<P-G>
I think most people interested in Neo900 will be coming from modern phones they just can't stand any more (like me).
archtimmy has joined #neo900
<drathir>
if parts fit the present n900 case that access to inside is really smart and easy, im was worried when first time open my n900, really woried similar to first flash the n900 which one take less than 5min im pretty sure something was wrong even if say ok, bc of that sort time...
<DocScrutinizer05>
you can even comlete the whole procedure from start to end in less than 5min when you got a sufficiently fast internet connection so my script can download the stuff swiftly
paulk-collins has joined #neo900
FIQ has quit [Read error: Connection reset by peer]
kerio has quit [Read error: Connection reset by peer]
FIQ has joined #neo900
kerio has joined #neo900
SylvieLorxu has joined #neo900
FIQ is now known as FIQ
<drathir>
DocScrutinizer05: yea but first time was shocked of the speed, and almost sure not sucesslul even the flasher say all ok ...
<drathir>
now i know its normal...
<DocScrutinizer05>
:-)
<DocScrutinizer05>
yeah, on GTA02 it took like 40 minutes to flash the pathetic 128MB rootfs
<kerio>
wut
<DocScrutinizer05>
N9 flashing also took some 25min or sth
<DocScrutinizer05>
maybe even loger, depending on parameters
<kerio>
all of my wut
<DocScrutinizer05>
longer*
<DocScrutinizer05>
kerio: "--erase-all"
<DocScrutinizer05>
seems they triple-erased all 16GB
<Pali>
trim equivalent for mmc controller?
<DocScrutinizer05>
no idea
<DocScrutinizer05>
I only know it took like >20min and one-click-flasher even said it might take way longer
<Pali>
DocScrutinizer05: will mmc controller and emmc chip in neo900 supports trim?
<DocScrutinizer05>
eMMC chip not decided yet, controller is... the OMAP3 one
<kerio>
DocScrutinizer05: i'm fairly sure that a flash_eraseall is not supposed to take that long
<DocScrutinizer05>
I *guess* it's not a controller limitation but rather a generic command controller hands through to eMMC
<kerio>
Pali: is "discard" a thing, for uSDs?
paulk-collins has quit [Remote host closed the connection]
<Pali>
basically "discard" flag for kernel FSs is still experimental
<Pali>
and can cause lot of problems
<Pali>
specially on SSD with buggy firmwares
<Pali>
somebody said that there are also bugs in linux kernel with "discard" flag
<Pali>
calling fstrim is probably more safer
<DocScrutinizer05>
Pali: so you say "supports 'truncate' command" is a relevant selection criterion for our eMMC chip?
<kerio>
it would be a definite plus
<kerio>
if it actually works
<DocScrutinizer05>
ok, duly noted
<kerio>
but, like
<kerio>
i don't know if i'd pick a smaller eMMC with trim rather than a bigger one
<Pali>
if eMMC chip has good FW which support trim (I do not know how it is called in emmc context), then it is nice feature
<DocScrutinizer05>
yes, weighting is an issue. When we cannot get 128GB eMMC with that feature, but we can get 64 or 32GB, what shall we do?
<Pali>
I do not know how good is implementation of that command and how effective is...
<DocScrutinizer05>
also how much may it cost to have that feature, in bucks?
<DocScrutinizer05>
would we spend 5 bucks more per chip? 10?
<Pali>
The MultiMediaCard and SD ERASE (CMD38) command provides similar functionality to the ATA TRIM command, although it requires that erased blocks be overwritten with either zeroes or ones. eMMC 4.5 further defines a "discard" sub-operation that more closely matches ATA TRIM in that the contents of discarded blocks can be considered indeterminate (i.e., "don't care").
<DocScrutinizer05>
anyway "all eMMC are compatible", I'll appreciate any suggestions for a particular part/build to use
<Pali>
so it is not "truncate" command, but ERASE or "discard" sub-operation
<Pali>
first need to check what linux kernel supports
<Pali>
how it is stable (for emmc chips and for that omap3 mmc controller)
<DocScrutinizer05>
:-)
<Pali>
also ATA TRIM command for SSD SATA disks is not good
<Pali>
it requires that command queue must be flushed before command TRIM can be send
<Pali>
which takes some time...
<Pali>
as solution for this was invented queued trim command
<Pali>
but windows does not implement it, so manufactors does not implemented them in their FWs
<DocScrutinizer05>
>:-(
<Pali>
and some which have queued trim implemented (at least provide info that queued trim is supported), it can cause total disk erase (on Crucial SSD disks)
<Pali>
so linux kernel has special hooks for Crucial SSD disks to disable queued trim..
<DocScrutinizer05>
>:-(((
<DocScrutinizer05>
what a mess
<kerio>
rofl
Oksana_ has joined #neo900
<DocScrutinizer05>
anyway lemme say it once more: you folks are an awesome bunch of experts and it's a pleasure to develop stuff for and with you
Oksana has quit [Ping timeout: 255 seconds]
Oksana_ is now known as Oksana
che11 has quit [Ping timeout: 246 seconds]
<freemangordon>
DocScrutinizer05: yep, BR can be dumped. actually it is the same OMAP3 BR as in motorola milestone. exactly the same version
<DocScrutinizer05>
:-D
<DocScrutinizer05>
TA
<DocScrutinizer05>
(sidenote to tickle kerio: of course this still doesn't *guarantee* that it's the actual code that is used by CPU during boot, it still could be a fake)
<kerio>
DocScrutinizer05: if it's such a pleasure, shouldn't you pay us for the neo900?
<DocScrutinizer05>
kerio: I already do, ~ 8000 bucks per month I'd earn more when doing a silly industry momkey job
<freemangordon>
DocScrutinizer05: the problem is that this is not the only ROM code running :)
<kerio>
lack of earning is not loss
<kerio>
otherwise, RIAA/MPAA are losing literally trillions because of piracy
<kerio>
DocScrutinizer05: will the neo900 eventually earn a profit for you guys?
<kerio>
like, assuming all are sold
<DocScrutinizer05>
well, we hope for *some* profit, yes. For sure not the usual margin
<DocScrutinizer05>
actually profit starts when we can build a second batch
<DocScrutinizer05>
actually I hope for the profit being enough to enable building a second batch without all this crowd funding, just order and a 8 weeks later receive the package
<DocScrutinizer05>
the rpofit from first batch that is
<DocScrutinizer05>
unlikely that this ever will pan out though
<P-G>
Why wouldn't it pan out?
<arossdotme>
cus people don't put there money where there mouth is?...
<P-G>
No, I mean if we make something good, why wouldn't it sell?
<DocScrutinizer05>
because that would mean too high sales price for the first batch which would cause all sorts of problems starting from users not be willing to buy, to donors going after me to do nasty stuff to me
<P-G>
You already have pricing projections though, right? Isn't that how you're able to accept pre-orders?
<DocScrutinizer05>
we targeted at a 700 bucks per NeoN board and that's already getting tough and margin is negative
<DocScrutinizer05>
with a maybe 800 bucks per board we might break even. Still no profit
<P-G>
Well the exercise is in brand building. When more orders start coming in you can start buying parts in larger quantities and lower overhead, right?
<DocScrutinizer05>
or we leave out a few things like e.g. the eMMC completely and make the board cheap but not attractive anymore
<DocScrutinizer05>
volume discounts for parts start at different thresholds, usually in the 2500 to 3000 parts though
<P-G>
That ensures earnings scale faster than the number of orders though. That's when the real profit starts.
<DocScrutinizer05>
the major discount is R&D devided by number of devices, which obviously is "linear"
<P-G>
Also in selling parts and accessories aside from whole phones.
<DocScrutinizer05>
sorry, I'm absolutely not in the mood to dicuss this marketing stuff, it gives me allergic pimples
<P-G>
Lol, ok. I think there is potential though. :)
<DocScrutinizer05>
believe me, we're exploiting every little bit of "potential" we can dig up somewhere
<P-G>
I'm sure. You guys are smarter than I am. :p
<DocScrutinizer05>
bbl, cheers
n1cky has joined #neo900
<n1cky>
Hey guys, I was wondering if anyone of you have come across something like a USB modem that is more capable than just doing IP.
<n1cky>
Like a USB powered cell phone, that allows you to read text messages over a usb serial port, phone calls through the same means, and otherwise does USB RNDIS
<P-G>
They have but I don't know much about it.
<P-G>
Doc was telling me that the convention is to use a diler application, like SHR, to communicate through Hayes (AT) protocol with the modem or middleware.
<P-G>
As for the hardware, you will need a modem capable of communicating the protocols you want to use on the frequencies used in your region by your phone service provider.
<P-G>
I'm not sure what various service providers have to say about this but it is technically quite possible.
<P-G>
I can't really refer hardware but that's my understanding of the matter.
<n1cky>
thank you! That's a lot of very good info.
<DocScrutinizer05>
n1cky: basically all USB modem dongles more or less are what you want. You need to check if they support voice too
<P-G>
Another option, depending on what you're trying to accomplish, might be VoIP like SIP.
<DocScrutinizer05>
yes, SIP over 3G is absolutely working, if your carrier allows it
<DocScrutinizer05>
mine (O2 Germany) does
<DocScrutinizer05>
and it works just fine
<P-G>
Do modem dongle shoppers need to look out for CDMA compatability or whatever that Asian SMS protocol is?
<DocScrutinizer05>
at east with sipgate.de
<DocScrutinizer05>
at least*
<DocScrutinizer05>
modem buyers need to make sure the modem is for their region/Radio-Technology
<P-G>
Yeah, ok.
<DocScrutinizer05>
which usually is no issue when you buy "locally"
<kerio>
DocScrutinizer05: SIP over umts sounds better than a umts voice call, right?
Kabouik has joined #neo900
<drathir>
kerio: sip better if unlimited net access...
<DocScrutinizer51>
better in which regard? sound, like audio qality? depends on codec SIP negotiates with far end
<DocScrutinizer51>
kerio: ^
<kerio>
yes, audio quality
vakkov has quit [Ping timeout: 245 seconds]
<freemangordon>
Pali: BTW bme-replacement didn't manage to calibrate the battery. I discharged the device until mce shut it down, connected charger and kept it connected until the led turned green. Still "battery not calibrated" in dmesg log
<Pali>
you need to charge and discharge
<Pali>
not discharge and charge :-)
<freemangordon>
hmm,ok. well, lets see :)
vakkov has joined #neo900
<DocScrutinizer51>
freemangordon: you might want to check my bq27k-calibrate.sh, at least for reference
<enyc>
TLS-SIP and ZRTP would be helpful for portable-use...... =)
<kerio>
or my calibratebq27200, for usage
<DocScrutinizer05>
indeed. Thus somebody already porting twinklephone would be really great
<DocScrutinizer05>
dunno if it knows TLS, but I know it knows SIPS and ZRTP
<freemangordon>
DocScrutinizer05: I am sure it will work, but I want to test how bme replacement behaves
<DocScrutinizer05>
sure, you just can see in script what to look for to even *start* (and complete) a valid learnung cycle
phre4k has joined #neo900
<DocScrutinizer05>
I guess you're interested in BME behavior *in relation* to learning cycle
<DocScrutinizer05>
so in script you see what to look for to see status of learning cycle
<DocScrutinizer05>
bq27k-detail should already give away a few details
<DocScrutinizer05>
and bq27k-calibrate shows the sequence and bit values of the flags that are needed
<DocScrutinizer05>
simply put: charge battery until bq27200 says "valid learning cycle", then discharge without ever charging in between until bq27200 signals "learning cycle complete"
mvaenskae has joined #neo900
<DocScrutinizer05>
which should be well *before* mce shuts down device
<DocScrutinizer05>
a mere "didn't work2 doesn't help much to debug stuff ;-)
<freemangordon>
well, I think I provided enough info to identify there is a pebcac :)
<freemangordon>
DocScrutinizer05: you don;t get the point - I am playing (l)user here. The fact that I did it in the wrong way means the instructions are missing or the process is not intuitive. So, based on that experience I will either prepare a patch or discuss with Pali what can be improved. or both.
<DocScrutinizer05>
yes, but to do that you first need to know whatt was the problem
<freemangordon>
the problem was - I did it the wrong way :)
<DocScrutinizer05>
there's no patch for charging battery till full
<DocScrutinizer05>
it's just something that should usually happen during normal use
<freemangordon>
sure, but we can hint the user - "your battery is not calibrated, let it charge to full and don;t charge the device until it shuts off" or somesuch
<DocScrutinizer05>
you failing to do that charging doesn't tell us anything really
<DocScrutinizer05>
yeah, either that, or you provide a calibrate-bq27k.sh which does exactly this intructions
<DocScrutinizer05>
echo 'Please charge battery! Use fastcharger!';
<DocScrutinizer05>
it's all in there
<freemangordon>
yep. and similar stuff should exist in bme-replacement IMO
<DocScrutinizer05>
no, bme-replacement is not responsible for instructing user to calibrate chip
<freemangordon>
well, battery-applet then
<DocScrutinizer05>
arguable. I think maybe not
<DocScrutinizer05>
anyway afk
<DocScrutinizer05>
o/
<DocScrutinizer05>
((battery-applet)) a tiny indicator for VDQ=1 would for sure help and fit into the system design / task definition of that applet
<DocScrutinizer05>
I already gave a sugestion how to signal CI=1 even in bme-replacement data, by setting last digit of the uAh value to 1 instead of the usual 0
<DocScrutinizer05>
or sth similar that is visible even in original battery-applet. Which been the idea to keep the new "bme" compatible with the original applet/userland-at-large, right?
<kerio>
pali's battery applet is only tangentially related to bme replacement
<kerio>
the original battery applet would still work
<DocScrutinizer05>
yes, that's what I said
<DocScrutinizer05>
so bme could deliver only "NAC Nominal Available Capacity" that end in "0" or at least in even number, *unless* CI=1 when every decent battery-applet would show the value bme replacement now delivers, with UNEVEN / !=0 last digit
<DocScrutinizer05>
informed users would know last digit in [13579] means CI=1 while last digit in [02468] means CI=0
<DocScrutinizer05>
this would also make new battery-applet compatible to original BME, not trying to read out some "CI" value that's not available in original BME API
<DocScrutinizer05>
which actually is the real point in this concept
<DocScrutinizer05>
prolly to avoid floating BKBAT pin spoil the "...or (VBAT > 2.1 V and VBAT > backup battery voltage [BKBAT])"
<DocScrutinizer05>
would be annoying when UPR would brown out on VBAT <2V8 just because BKBAT is floating at 3V
<DocScrutinizer05>
final schenatics verification would have caught it ;-)
<DocScrutinizer05>
real full evaluation means reading the full 937 pages and check every pin of TPS65950, and read all pages (well almost) of SoC TRM and check every pin of SoC
<DocScrutinizer05>
seems we don't want to use this 24bit parallel mode, right?
<DocScrutinizer05>
so we'd need something that can cope with our 3 lanes + clock diferential signal
<DocScrutinizer05>
or we need to completely rework another 16 GPIO
<DocScrutinizer05>
which sounds like a nogo for maemo compatibility
<wpwrak>
i wonder if there's some arm that can create a good virtual machine. then we could virtualize the 3730 hardware and use a chip that has the 1000+ io pins we'd want :)
<wpwrak>
(hmm, thinking of it, i hope i didn't give you an idea ...)
<DocScrutinizer05>
nah, what we need is sth like that TFP410 but not with 24 data-in but with differential 3 lanes + clk input
<DocScrutinizer05>
(give idea) actually you did, but that idea didn't make it to some result, except for a short moment of me pondering to suggest OMAP5 to you
<wpwrak>
phew, i'm relieved :)
<DocScrutinizer05>
I wonder if such chip with SDI input converting to a more commonly used digital signal (or even VGA) is that unusual
<wpwrak>
oh wow. so somebody is actually using that :)
<DocScrutinizer05>
anyway the chances to find a converter chip for that crap are 0 ... Kelvin
Pali has quit [Remote host closed the connection]
<DocScrutinizer05>
and I don't think we can find another mode OMAP supports that can get away with just 8 pins, instead of 24 + x
<DocScrutinizer05>
particularly not a mode that uses only 8 pins and could be found on any converter chip with free documentation
<DocScrutinizer05>
a 3 serial * 8 parallel would be within reach of what we *might* be able to implement, from OMAP side regarding GPIO already used for other functions
<DocScrutinizer05>
and also might be a somewhat reasonable format for a "free" converter
<DocScrutinizer05>
ds2: what you're talking about?
<DocScrutinizer05>
yes, battery stuff
<wpwrak>
DocScrutinizer05: i still fondly remember the meeting between raster and the smedia (glamo) guys, where he accusingly read them the abysmal performance figures he got. they were quite surprised ... because they themselves never had seen their critter run that FAST !
<ds2>
get the DSI protocol opened up
<ds2>
it is the most reasonable approach
<DocScrutinizer05>
aha
<DocScrutinizer05>
and how does this give us a DSI->VGA converter, even if it *COULD* be done (which it clearly is not )
<ds2>
fpga
<DocScrutinizer05>
OMG
<DocScrutinizer05>
are you trolling?
<ds2>
DSI is just a serial protocol that has all the same info as the DPI stuff
<ds2>
no
<ds2>
there is IP for deciding DSI but it cannot be released
<ds2>
well, technically, for its successor protocol but it is similar
<DocScrutinizer05>
of the 24 bits for RGB parallel, only 8 are available
<ds2>
those are GPIOs, why can't they be moved?
<DocScrutinizer05>
so we can't do what beagleboard did
<ds2>
you can reduce it down to 16bits
<DocScrutinizer05>
they can't be moved because of a) we're generally short on GPIO already and b) the maemo OS depends on them being used the way they are
<wpwrak>
hmm. if we have part of the RGB bus, that could still be enough. we'd just have to encode things (in sw) accordingly. i.e., change the rendering engine.
<ds2>
hmmm
<ds2>
what about the alt. video pinouts?
<ds2>
I think the xM uses the legacy pins
<DocScrutinizer05>
we could free up a maybe 2 or three additional GPIO for clock and hsync/vsync or whatever
<wpwrak>
and a proof of concept implementation would just set up things for a static pre-computed image, so no need to dive into sw stuff that may be messy
<DocScrutinizer05>
wpwrak: what are you talking about? dithering?
<DocScrutinizer05>
we don't want to rewrite the complete OS to use the GPIO we found would be available
<ds2>
just the GPIO drivers
<wpwrak>
and there, look at the images. the quality is surprisingly good.
<DocScrutinizer05>
yes, of course it's a kernel thing. so we either patch our userlabd or we massively patch kernel away from upstream and not compliant with it, to make GPIO160 still mean "MMc card detect"
<wpwrak>
probably sufficient for presentations and such
<DocScrutinizer05>
(random example)
<ds2>
it isn;t that massive of a patch
<ds2>
worse comes to worse, put a latch
<ds2>
latch in the values prior to switching and on GPIO change, relatch
<DocScrutinizer05>
wpwrak: so we implemet high quality VGA or even digital video out with a 8bit colorLUT quality? that doesn't make sense
<ds2>
it'll glitch the video when it happens but...
<wpwrak>
i didn't say it was "high quality". maybe we could call it "practical quality" :)
<DocScrutinizer05>
you again lost me, but I bet it's miles away from what we need
<DocScrutinizer05>
wpwrak: that's nonsense
<DocScrutinizer05>
we could as well use CVBS then
<ds2>
'k
<ds2>
I'm out then.
<wpwrak>
RGB may be easier to implement than CVBS
<DocScrutinizer05>
the idea is to have a video output that does good quality 800*480@30fps minimum
<DocScrutinizer05>
no, we already _have_ CVBS
<kerio>
yeah but it would be hard to implement!
<DocScrutinizer05>
what we don't have is a a 800*480*24bpp
<wpwrak>
(cvbs) that's TVOUT then ?
<DocScrutinizer05>
kerio: you gave me the rest now
<DocScrutinizer05>
afk
<kerio>
i what
<wpwrak>
kerio: in german "then rest geben" = to finish off, to kill (usually used figuratively)
<kerio>
i hope he means he's going to rest
<wpwrak>
maybe he'll do that, too :)
<DocScrutinizer05>
work package goal: find out if OMAP3 can do 8bit parallel * 3 RGB values serial via an 8 bit wide data bus consisting of DSS_DATA[10:15,22,23], using some arbitrary other pins for clock, hsync, vsync. IF YES, find a converter chip latching 3 8 bit values and converting them into a VGA signal
<DocScrutinizer05>
IF NO, forget about any high quality video output
<kerio>
oh god, we broke doc
<kerio>
he seriously put some thought into bitbanging vga