<Joerg-Neo900>
note that the very important initialization phase (on plug in of ECI headset) is missing in above snapshots. I hope it can get RE'ed from the existing sources
<Joerg-Neo900>
in the last screenshot I guess you can easily tell apart headet-originated and phone-originated pulse sequences by different bottom voltage
<Joerg-Neo900>
it *looks* like in the first two pulse bursts, the first pulse (low) is from HS, sort of "attention", then phone answers with a not-so-low command and HS sends reply to command. The last far off right of the 3 bursts seems initiated by phone then
<Joerg-Neo900>
you also see a little ringing at upper part of falling edge of signals coming from HS, which makes sense since the 1m of cable is between HS and scope
<Joerg-Neo900>
no idea what that is, doesn't exactly look like ringing
<Joerg-Neo900>
must be something with the hw logic, maybe switching the pin in HS MCU to output-H, then to output-L ?
<wpwrak>
looks more like some pull-down activation
<Joerg-Neo900>
UH! MCU comimg oit of suspend, of course
<wpwrak>
or that :)
<Joerg-Neo900>
so it draws a lil bit more of power since it's active
<Joerg-Neo900>
anyway seems this should be feasible to bitbang in sw
<Joerg-Neo900>
we did pretty much same for HDQ in OM
<Joerg-Neo900>
did I mention that my reference S60 android device reproducably boots hard when plugging in a Nokia headset? ;-P
<Joerg-Neo900>
simply stalls and gets kicked by watchdog X-P
<Joerg-Neo900>
I still wonder if that's *totally* fubar drivers or a nasty hw defect
<Joerg-Neo900>
btw N97-mini has same display hinge like N950, just over the full width of display, so any mech forces would not push the back of the display since the two hinge joints are pretty close to the left and right end of display
<Joerg-Neo900>
huge mistake in Nokia's ME/ID department, for N950
<Joerg-Neo900>
Pali: in N900 you may use the video mux aka TVOUT_EN signal to pulse micbias low for ECI
rootman has quit [Ping timeout: 256 seconds]
<Joerg-Neo900>
set TVOUT pin of OMAP to low for that
<how900>
atk: quite well it seems. Your method works.
<atk>
Credit goes to that guy on stackoverflow :P I only found the thread and adapted the method for this purpose.
<how900>
you did well atk!
<atk>
Well, I'm happy to hear that it worked anyway. Now I was going to ask about firmware/software related work for Neo900, I asked about 4 months ago and got pointed at some porting taskforce or something but I can't quite remember anymore.
<atk>
It was regarding some reverse engineering that needed doing, I'd be happy to contribute.
<Pali>
Dec 22 15:40:27 Pali-Latitude kernel: [21595.259065] ata5: SATA link down (SStatus 0 SControl 300)
<Pali>
that is last line
<Joerg-Neo900>
exactly
<Joerg-Neo900>
reboot
<Pali>
how can I convert that ata5 to /dev/sd*?
<Joerg-Neo900>
hope for the best
<Pali>
to identify disk?
<Joerg-Neo900>
if only I knew
<Joerg-Neo900>
cat /etc/fstab?
<Joerg-Neo900>
prolly nope
<Joerg-Neo900>
try df -h
<Pali>
# df -h
<Pali>
Segmentation fault
<Joerg-Neo900>
your HDD with /bin is dead
<Pali>
so in best case just system is damaged...
<Pali>
/ is on SSD, /home with data on HDD
<Joerg-Neo900>
yes
<Joerg-Neo900>
in very best case the interface went down due to a glitch. This shouldn't happen but rarely it does
<Joerg-Neo900>
IOW a reboot might magically fix it
<Joerg-Neo900>
or you won't be able to reboot at all
<Pali>
/ is on on sdb<something>, /home on sda2
<Pali>
but I do not see sdb in /sys/class/block/
<Pali>
just sda!
<Joerg-Neo900>
the IF went down, so...
<Pali>
so looks like sdb (with /) was disconneted by kernel
<Joerg-Neo900>
yes
<Joerg-Neo900>
kernel: [21595.259065] ata5: SATA link down
<Pali>
yes, looks like
<Joerg-Neo900>
reboot from a live CD
<Pali>
ok, I will try to reboot and will see what happened
<Joerg-Neo900>
print your fstab!
<Joerg-Neo900>
you'll need it when you try to mount volumes in said live CD
<Pali>
luks encrypted
<Joerg-Neo900>
ouch!
<Pali>
so just /dev/mapper in /etc/fstab
<Joerg-Neo900>
good luck!
<Pali>
I have backup of GPT table of that disk, but not here where I'm :-(
<Pali>
and have also backup luks headers
<Joerg-Neo900>
try hdparm to check sdb, but I guess a IOerr is all you see
<Pali>
no sdb in /dev
<Pali>
just sda
<Joerg-Neo900>
ooh right, the interface is down
<Pali>
so I would need to reset sata link
<Joerg-Neo900>
there was some nasty arcane way to re-init interface
<Pali>
yes, via /sys it should be possible
<Pali>
some rescan file
<Pali>
or something like that
<Joerg-Neo900>
sth like that, yes
<Pali>
going to file it
<Joerg-Neo900>
anyway I recommend you call a sync:sync before your reboot
<Joerg-Neo900>
odds are reboot will freeze
<Joerg-Neo900>
hey, you could try a pivotroot ;-D
<Pali>
sda is there: /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
<Joerg-Neo900>
see if you can find a spare storage drive for your root fs
<Joerg-Neo900>
I guess when a SSD blows chunks, it's dead
<Joerg-Neo900>
but... you only know when you reboot. And even if it comes back, you won't know if that's stable
<Pali>
shit, window manager crashed
<Pali>
now I can just type in IRC window
<Joerg-Neo900>
shoot the boot :-D
<Pali>
going to reboot, nothing more...
<Joerg-Neo900>
good luck!
Pali has quit [Remote host closed the connection]
rootman has quit [Quit: Lost terminal]
xmn has joined #neo900
Kabouik has quit [Quit: Leaving]
jonsger has quit [Quit: jonsger]
<freemangordon>
Joerg-Neo900: pong
<Joerg-Neo900>
ooh sorry, that was an advice to atk
<freemangordon>
aah :)
<Joerg-Neo900>
he wants to hack away with maemo RE
<Joerg-Neo900>
aiui
<freemangordon>
good
<Joerg-Neo900>
:-)
<freemangordon>
but Pali won;t be much of a help there
<Joerg-Neo900>
so I said: ping freemangordon!
<freemangordon>
(16,08,22) Joerg-Neo900: ping Pali and freemangordon
<Joerg-Neo900>
particularly with broken SSD he won't, no :-)
<freemangordon>
:p
<freemangordon>
yeah :(
<freemangordon>
but he said this is not SSD, unless I misread it
<Joerg-Neo900>
"only" system
<freemangordon>
well, if $home is on another drive, he won't lose much
<Joerg-Neo900>
[2016-12-22 Thu 15:51:19] <Pali> / is on SSD, /home with data on HDD
<freemangordon>
Joerg-Neo900: BTW, with my latest h-d fixes to gtk3 h-d, the start memory isage is ~ 20 MB :)
<Joerg-Neo900>
hmm, I have no reference numbers
<freemangordon>
check on n900
<freemangordon>
it is more than that.
<freemangordon>
however there is no hildon-home and hildon-status-menu here
<Joerg-Neo900>
did you ever wonder about ECI?
<freemangordon>
no :)
<Joerg-Neo900>
do you know which protocol(""?) android/apple/AHJ wired headsets use, if any?
<freemangordon>
no idea, sorry
<Joerg-Neo900>
my Cat S60 reboots hard (from WD timeout on frozen android) when plugging a Nokia/OMTP headset X-P
<freemangordon>
:)
* Joerg-Neo900
can't come up with another explanation than "total fsckup of drivers, coder adicted to crack" or even a nasty hardware bug for culprit of such effect
jh5 has joined #neo900
galiven has joined #neo900
galiven__ has quit [Ping timeout: 258 seconds]
jh5 has quit [Quit: WeeChat 0.4.2]
Kabouik has joined #neo900
<Joerg-Neo900>
in *.git/hooks/pre-commit.sample
<Joerg-Neo900>
if git rev-parse --verify HEAD >/dev/null 2>&1
<Joerg-Neo900>
then
<Joerg-Neo900>
against=HEAD
<Joerg-Neo900>
else
<Joerg-Neo900>
# Initial commit: diff against an empty tree object
<Joerg-Neo900>
honestly now? is anybody supposed to understand (and memorize) "against=4b825dc642cb6eb9a060e54bf8d69288fbee4904"?
<Joerg-Neo900>
o.O
<how900>
against=$COMMIT_REF
<how900>
no only programs should remember commit refs :)
<Joerg-Neo900>
how's 4b825dc642cb6eb9a060e54bf8d69288fbee4904 an empty tree object?
<Joerg-Neo900>
or is this a random string assumed to not exist?
<how900>
that's the initial commit, so yes, the tree is empty
<Joerg-Neo900>
how am I supposed to know 4b825dc642cb6eb9a060e54bf8d69288fbee4904 is the initial commit?
<Joerg-Neo900>
is this documented anywhere in git manpages?
<Joerg-Neo900>
I have a strong suspicion that I don't really get how that's supposed to work
<how900>
I guess the comment is here to tell you this is the initial commit.
<how900>
Otherwise, yes, there's no reason to believe so :)
<Joerg-Neo900>
sorry, that doesn't help me out in any way
<Joerg-Neo900>
it's not about the comment, it's about a fixed hash used in a generic script
<Joerg-Neo900>
supposedly when the git repo is empty
Kabouik has quit [Quit: Leaving]
<Joerg-Neo900>
what this thing tells me is "4b825dc642cb6eb9a060e54bf8d69288fbee4904 is an empty tree object"
<Joerg-Neo900>
later usage of $against: git diff --cached --name-only --diff-filter=A -z $against; and git diff-index --check --cached $against --
<Joerg-Neo900>
I can see how a "git diff-index --check --cached HEAD --" makes sense. But I completely fail to grok the semantics of "git diff-index --check --cached 4b825dc642cb6eb9a060e54bf8d69288fbee4904 --" in a script
<Joerg-Neo900>
is this a well known hash of some variable in git = "" (empty string)? or is this a string the user should edit to whatever correct value derived from the particular git repo they plan to use that hook with? or is it simply a bogus value that only has to have one property: not exist in that git repo?
Kabouik has joined #neo900
Kabouik has quit [Client Quit]
Kabouik has joined #neo900
mzki has quit [Ping timeout: 258 seconds]
<Joerg-Neo900>
I suppose only the latter makes sense, particularly since the repo is supposed to be empty for initial commit, so I has rather used against=bad000bad000bad000badbad000
galiven_ has joined #neo900
galiven has quit [Ping timeout: 258 seconds]
wpwrak has quit [Remote host closed the connection]
<Joerg-Neo900>
hmmm, seems git checks if the hash is valid, must have a built-in checksum of sorts - ohmy
<Joerg-Neo900>
seems 4b825dc642cb6eb9a060e54bf8d69288fbee4904 is a magic hash
<Joerg-Neo900>
while afac499523f03b8a80caa5e257fac8e1fb956246 is only valid in eeshow repo and throws error on hw
<wpwrak>
oh, that's a just the empty tree. so that's the same everywhere :) kinda like sha1sum </dev/null :)
<Joerg-Neo900>
hah!
<Joerg-Neo900>
thanks! :-)
<wpwrak>
git show <hash> shows you what something is/contains
<Joerg-Neo900>
:-D \o/
<wpwrak>
there's also git cat-file that can be useful. e.g., git cat-file -s git cat-file -p 4b825dc642cb6eb9a060e54bf8d69288fbee4904
<wpwrak>
-> 0
<wpwrak>
(-s is for size. it has more options, e.g., -p for "pretty")
<wpwrak>
the general structure of a git repo is (simplifying a little): 1) you have commit objects, which consist of the meta-data (names, dates, commit message), and a pointer to a "tree"
<Joerg-Neo900>
I suspect they didn't document that (the 'magic' hash) in git's manpages?
<wpwrak>
2) a "tree" is a directory, a list of name -> object. there object can be another tree (for subdirectories) or a "blob"
<wpwrak>
3) a blob is then the file content
<Joerg-Neo900>
is it really the content of a diff?
<Joerg-Neo900>
s/of/or/
<wpwrak>
the content. unlike svn, git stores no diffs
<Joerg-Neo900>
makes sense, since otherwise reading content would take ages for old large repos
<wpwrak>
as it does, in svn ;-)
<Joerg-Neo900>
I jist wonder why for zuse's sake they use hashes instead of more meaningful names
<wpwrak>
git can still "compress" by simply reusing blobs or trees. so you don't get a full copy of the whole repo in each commit
<Joerg-Neo900>
yeah, I seen that mentioned, it uses hardlinks a lot
<Joerg-Neo900>
and yes, seems two meta info packages could point to same blob hash
<wpwrak>
"meaningful names" are not really convenient. also, what would you do when things get renamed over time ?
<Joerg-Neo900>
what am I supposed to do? I mean, what am I doing right now?
<wpwrak>
besides, from a user perspective, the only visible hashes are those of commits. and you can tag commits with "meaningful names", so you don't need to use the hash
<wpwrak>
with hashes, the hash stays the same whatever the name of the thing in question is. if the thing included some name (as part of its identifier), that would get difficult
<Joerg-Neo900>
hmm
<wpwrak>
(where i'm thinking "path" when saying "name")
<Joerg-Neo900>
I don't think this would make a difference if you use sha1 or a more human-readable algo to create the hash
<wpwrak>
and once you're at a point where you see lots and lots of hashes in your daily work (e.g., writing something like eeshow), you've probably made your peace with them ;-)
<Joerg-Neo900>
when the file name or whatever changes later, the worst effect is the 'hash' doesn't match the true filename anymore
<wpwrak>
the trick is that the hash identifies the content. that's how git can efficiently optimize things. to add <stuff>, generate <stuff> and hash it, then add the hash .. wait it's already there. great, we can reuse.
<Joerg-Neo900>
oooh the hash is for the complete content?
<wpwrak>
the content of the object in question
<Joerg-Neo900>
ugh
<wpwrak>
which may contain hashes of other objects
<Joerg-Neo900>
I see
<wpwrak>
so a commit does "uniquely" refer to the content of the repo (under that commit) and the history leading up to it
<wpwrak>
this also means that, if you decide to change the history, the hashes no longer match
<atk>
git problems?
<Joerg-Neo900>
hehehehehe
<Joerg-Neo900>
atk: just the usual understanding problems on my side :-)
<atk>
I see
<Joerg-Neo900>
atk: the questiomn been "why is a hardcoded hash being used in a jook template?"
<Joerg-Neo900>
atk: meanwhile it degarded to my usual rambling of "why is git so untangible and cryptic?"
<wpwrak>
yeah, linus did a good amount of out-of-the-box thinking for git. it's rather alien when you come from "traditional" version control, but it makes a lot of sense.
<wpwrak>
plus, it can do things that would just shred any traditional system
<atk>
git interactive rebase is currently my favourite feature.
<wpwrak>
atk: i love it, too :)
<atk>
when you're preparing a bunch of patches it's invaluable
<atk>
when you forget something 15 commits back and want to fix it in that commit
<atk>
or splitting commits
<atk>
that's just the tip of the iceberg
pirateman has joined #neo900
<wpwrak>
plus, it lets you impress the world with the unfailing precision of your design process ;-)
<atk>
so where did Joerg-Neo900 find this magic hash?
<atk>
:P
<pirateman>
hi
<atk>
pirateman: hello
<Joerg-Neo900>
atk: in *.git/hooks/pre-commit.sample
<atk>
ah, I see
<Joerg-Neo900>
atk: and I wondered if they bothered to document that in git manpages ;-P
<pirateman>
I asked the father noel the n900 \o/
<pirateman>
oups NEO900
<Joerg-Neo900>
wpwrak: I now also see a maijor flaw in my suggestion to edit the *content* of files rather than not committing them at all :-D
<Joerg-Neo900>
in 15 or 20 years you'll have succeeded to convince me of git ;-)
<Joerg-Neo900>
just occurs to me that btrfs maybe also uses those content hashes, since it claims de-duplication
Pali has joined #neo900
<Pali>
looks like after disconnecting disk from (m)sata slot and inserting it again, everything is working...
<Pali>
I did whole block device backup before fscking just in case
<Pali>
fsck just recovered journal, no other problem...
<Joerg-Neo900>
good! :-) congrats
<Joerg-Neo900>
I already wondered if I should suggest to check if jack was loose
<Joerg-Neo900>
reminds me to update my emergency fallback rootfs partition on HDD
<Joerg-Neo900>
O also have SSD for /
<Joerg-Neo900>
I*
<Joerg-Neo900>
but I try to keep a dup on HDD, as alternative boot device into same system
Kabouik has quit [Ping timeout: 258 seconds]
<Joerg-Neo900>
those SSD are fast like hell, but I guess they are not really susceptible to smartmon prefail warnings
<atk>
They should be.
<atk>
Apparently they're better at telling you they're failing.
<Joerg-Neo900>
oh?
<atk>
Really apparently the main failure mode is running out of a decent amount of spare blocks which haven't had their read/write limits exceeded. (Apparently SSDs keep a spare set)
<Joerg-Neo900>
:nod:
<atk>
I imagine what smart monitoring tools will tell you might be different (might have to do some research to work out which values to care about) but from what I've been told they still give you ample warning before failing.
<wpwrak>
Joerg-Neo900: editing content wouldn't make things much worse at the hash level, since also omitting files means that the tree and thus the commit hash change
<Joerg-Neo900>
ooh right
<Joerg-Neo900>
dang, tricky stuff
<wpwrak>
Joerg-Neo900: however, editing content would mean that we'd have to get between git log and git am, and process the patch data that gets passed between them, including all the little extensions that may or may not be documented