<DocScrutinizer>
NB the latter is from the 1970s, still unchanged and available, except for the original set obviously been from a time where PNP was standard, GND=+, and NPN really exotic stuff (no kidding)
<wpwrak>
DocScrutinizer: seems that some EEs were begrudging us the obfuscated C contest ...
<DocScrutinizer>
God, I *loved* this Braun Lectron stuff back when I was 12
<Fusin>
installed yesterday Haiku on an ol eeePC701
<DocScrutinizer>
morning wolfspraul
<Fusin>
hi Doc
<DocScrutinizer>
hi Fusin
<Fusin>
of couse too: hi wolf ;)
<DocScrutinizer>
kicks his eeePC701
<Fusin>
funny little box
<DocScrutinizer>
battery lasted like 6 months
<Fusin>
the right size for takin' with you, when you make longer sessions @ toilet :->
<DocScrutinizer>
once suspended to ram and forgotten, it was dead
<DocScrutinizer>
special inferior Taiwan 701 version
<wpwrak>
up to 6 months battery life doesn't sound too bad. many laptops don't even manage 6 hours ;-)
<DocScrutinizer>
haha, I knew somebody would say this
<larsc>
took me some self-control to not say it ;)
<DocScrutinizer>
lol
<kyak>
wejp: there is no option to select 0.9.32 uClibc within the backfire, it was not supported. You need to build trunk, where 0.9.32 is enabled by default. btw, the current image is based on backfire and uses 0.9.30.1 uClibc..
<DocScrutinizer>
of course the battery is sealed (ultrasonic welded) - no way to open this thing without cutting off 2 fingers of your hand
<Fusin>
DocScrutinizer: that left 3 for use, isn't that enough?
<DocScrutinizer>
what if my estimation been a bit off
<wejp>
as the current firmware image seems to be incompatible with earlier ones, i have been trying to rebuild an up-to-date toolchain from scratch. but this fails unfortunately. when building the minimal gcc, configure stops with "checking for C compiler default output file name... configure: error: C compiler cannot create executables" any ideas what's going on there? the wiki is of no help :/
<whitequark>
post the relevant error from config.log
<wejp>
how do i find the relevant error from that file?
<whitequark>
find the line with your error message (C compiler cannot create executables)
<wejp>
at first sight the config.log looks okay to me
<wejp>
there is no such line in the config.log
<whitequark>
there is a lot of configure scripts in gcc source
<wejp>
let me check if there are other config.log files in the directory
<wejp>
looks like the assembler is doing something wrong there
<whitequark>
something is seriously screwed up in your gcc
<wejp>
that is strange, it works fine in all other cases
<wejp>
ah, found the problem. it is not my gcc but the configure script that is screwed up. it fails when the working directory is in the PATH
<wejp>
looks like it is compiling okay now. thanks for pointing me in the right direction
<kyak>
wejp: the current image IS compatible with previous ones, see my comment here soem hours ago
<kyak>
however, this doesn't have anything to do with the error you got..
<wejp>
i know, the error is unrelated to that, but it looks like it is not compatible. i don't know when something changed though. it does not necessarily have to be the last image, but could very well be an earlier one
<wejp>
i skipped a few updates
<kyak>
there was only one release based on trunk (using 0.9.32), long time ago.. You must be very outdated anyway
<kyak>
that broke binary compatibility
<kyak>
but then images were based on backfire again
<wejp>
my old toolchain was based on 0.9.30.1, so that wasn't it obviously. i thought it could have been an uclibc update, because similar behavior (application just terminating unexpectedly) sometimes happend with such upgrades
<mth>
kyak: would you be interested in reviewing Ayla's work on gmenu2x in the install_locations branch?
<mth>
we want to merge it to master, but it would be good if someone checks whether it breaks stuff on the NanoNote first
<kyak>
mth: sure, i'll have a look (it could take some time though)
<mth>
maybe Ayla can explain what the changes do, to speed up reviewing?
<kyak>
this would be helpful, of course
<kyak>
i remember he mentioned once the changes were related to read-only rootfs of some other device, so user setting for gmenu2x need to live in user's home dir
<mth>
yes, the rootfs for OpenDingux is read-only
<mth>
ah, there he is
<mth>
in general unix apps shouldn't write in their install dir, but with a read-only rootfs it's not a should but a must
<kyak>
of course
<kyak>
moreover, these apps shouldn't depend on their configuration files being in CWD
<mth>
indeed
<kyak>
cd /usr/share/gmenu2x && ./gmenu2x is plain awful
<mth>
well, Ayla fixed those things and tested it on OpenDingux, where it works
<mth>
but we'd like to check that it won't break on the NanoNote before merging it to master
<kyak>
how should i do? merge remotes/origin/install_locations to master and see how it builds/works on NanoNote?
<kyak>
or just work on remotes/origin/install_locations?
<kyak>
(i.e. checkout this branch only)
<mth>
I think testing the branch should be sufficient
<mth>
but Ayla recently merged the master changes into install_locations, so merging back is unlikely to cause serious conflicts
<kyak>
ah ok
<Ayla>
shouldn't be a problem, yes
<Ayla>
you guys are using a packaging system for the nanonote right?
<kyak>
yup
<Ayla>
I believe that you could create a package for gmenu2x
<kyak>
this is want i will do, a gmenu2x packages based on install_locations
<mth>
there was also a new configure flag added, I don't remember the details but probably Ayla does
<Ayla>
--enable-platform
<kyak>
so that would be --enable-platform=nanonote
<Ayla>
yes
<Ayla>
that is required as the data to install in /usr/share for the nanonote is not the same for the dingoo
<Ayla>
for instance, the key configs are different
<kyak>
well, it works if i start it as cd /usr/share/gmenu2x && ./gmenu2x :) I copied /usr/share/gmenu2x/gmenu2x as /usr/bin/gmenu2x.bin and try to start it like /usr/bin/gmenu2x.bin, and i get black screen
<Ayla>
/usr/share/gmenu2x/gmenu2x shouldn't exist
<kyak>
i figured that we still need that shell script for sourcing /etc/profile, because other apps (when started from gmenu2x) might require some env variables
<Ayla>
the binary should be /usr/bin/gmenu2x
<kyak>
Ayla: it exists because it's isntalled currently like that
<kyak>
this is the Install section of Makefile, i haven't modified it..
<Ayla>
sorry, my computer use to reboot from time to time
<kyak>
Ayla: hm... your last commit to origin/install_locations is from Thu Apr 14 19:35:50 2011.. Is it right?
<kyak>
ah, now i see, heh
<kyak>
i didn't do checkout correctly :)
<Ayla>
the last commit should be from the 1st june
<kyak>
that's right
<kyak>
Ayla: ok, it started now
<kyak>
but there are no icons
<kyak>
except for "Explorer"
<kyak>
and a new "emulators" section
<Ayla>
you have the settings, wallpapers icons?
<kyak>
yes
<kyak>
i can change the wallpapers, too
<Ayla>
well, on dingoo we don't have any global application that should be on gmenu2x from the start, so my guess is that it does search only on ~/.gmenu2x
<kyak>
i have /root/.gmenu2x directory
<Ayla>
but then that's a bug
<kyak>
that has these empty sections
<kyak>
ok, we have a number of applications that should be in gmenu2x by default
<kyak>
so it should search in /usr/share/gmenu2x/sections/, too
<kyak>
i just did "cp -r /usr/share/gmenu2x/* .gmenu2x/" and it works
<Ayla>
according to your install log, some sections are installed to /usr/share
<Ayla>
gmenu2x should be able to list them as well
<kyak>
seems that gmenu2x doesn't see those sections under /usr/share/gmenu2x/sections/
<kyak>
i see a bunch of
<kyak>
open("/usr/share/gmenu2x/skins/Default/icons/.png", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
<kyak>
open("/usr/share/gmenu2x/skins/Default/icons//usr/bin/hnb.png", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
<kyak>
i tries to open some files in /usr/share, but doesn't use correct naming for them
<kyak>
*it tries
<Ayla>
it searches for skin files in /usr/share, yes
<Ayla>
as well as on ~/.gmenu2x
<kyak>
Ayla: i don't see that gmenu2x searches for sections somewhere else other than GMenu2X::getHome()
<Ayla>
it does not
<Ayla>
but it should
<kyak>
Ayla: did you do it intentionally that data/platform/nanonote/ contains only scripts and sections?
<Ayla>
what should it contain?
<kyak>
skins
<kyak>
i noticed it because the data/skins/320x240/Default is different from the currently used
<kyak>
hm
<kyak>
i wonder how it got lost...
<Ayla>
the skin directory is the same that is on the repo
<kyak>
yeah.. i'm looking at history, looks like someone accidentally commited another default.png (older one)
<kyak>
anyway, skins are not meant to be platform-specific?
<mth>
skins should be resolution specific rather than platform specific, I think
<mth>
a platform implies a resolution, but multiple platforms can share the same resolution
<mth>
for example NanoNote and Dingoo are both 320x240
<kyak>
ok, i see
<Ayla>
it prevents duplication
<mth>
if we'd want to avoid the Qi-branded wallpapers on OpenDingux and vice versa, maybe we should have both shared and non-shared wallpapers
<mth>
or we just ship everything and let the user sort it out
<mth>
I don't mind if someone wants to use a Qi-branded wallpaper on the Dingoo for some reason
<mth>
in any case, the majority of the wallpapers is not platform specific
<Ayla>
I think you should be able to put platform-specific skins by putting them on data/platform/nanonote/skins/Default/
<mth>
ah, that may already work indeed
<kyak>
yeah, that sounds good
<kyak>
what's been done is already a great improvement. Btw, i'd like to mention an old bug: change the skin to something other than default, save, go to skins again and change back to Default, save. Restart gmenu2x, you'll see blank screen
<kyak>
i gave the link to a log where i tried to dig a little bit..
<mth>
completely blank screen or black wallpaper?
<mth>
I changed the image loading code completely in the last week
<mth>
not all of that has been merged yet to install_locations, I think
<mth>
but it's present in master
<kyak>
mth: it's completely black
<kyak>
not just the wallpapre
<mth>
I can't reproduce it on today's master
<mth>
"save" is just exiting the skins menu or is there more to it?
<kyak>
that's sad for me :)
<kyak>
i press "s" and it returns back to main menu
<mth>
that depends... can you still reproduce it on today's master?
<kyak>
and the new skin is applied (i think so)
<mth>
the new skin is applied here
<kyak>
yeah, i've just tried it with install_locations
<mth>
the Dingoo doesn't have an "s" button though
<mth>
no keyboard
<kyak>
so, after you applied the new skin, can i go back to skins and change to the first skin?
<mth>
I used the start button to exit the skin dialog
<mth>
yes
<mth>
and then I started "read", exited that and gmenu2x restarted just fine with the default skin
<kyak>
are we using the same "Default" skin?
<kyak>
i.e. with "messageBoxBg=#00000080"
<mth>
install_locations is *almost* up to date with master, but not exactly and the changes made after the last merge are related to image loading and SDL surfaces
<kyak>
i'll try again with the laster master tomorrow
<mth>
messageBoxBg=#ffffffff
<mth>
ah, my data is not from master, only my executable is
<kyak>
mth: this could be related to that "messageBoxBg=#00000080"
<mth>
that's RGBA?
<wpwrak>
RGB+alpha
<wpwrak>
er ... read "what" instead of "that" ;-)
<kyak>
mth: hmm.. when i apply that "2010-12-14" skin, it always goes back to "Default" after restart
<kyak>
i'll try to test more tomorrow.. have to go now
<mth>
I'll test a bit as well
<mth>
see you
<mth>
wpwrak: yeah, what I wanted to know is whether it was semi-transparent black or invisible blue ;)
<wpwrak>
mth: just set it to 0x00ff00ff and you'll see immediately ;-)
<wpwrak>
now, back to those most peculiar correlations i see in my "boundary scan". drive a pin to 1 -> reads as 1, drive it to 0 -> reads back as 1 too. grmbl...
<wpwrak>
(and the pin is nicely open. so it's all in the registers that somewhere get messed up.)
<mth>
the GPIOs can be pulled up or down depending on how they're configured
<mth>
and depending on how strong the outside world pulls, either the outside or the SoC wins
<wpwrak>
yes yes. i'm testing all four states. Z, R, H, and L. i also see the darn thing end up in all of them. just not the way the registers say it should.
<mth>
we had a misconfigured pin that worked fine on one Dingoo model and caused problems on a clone
<wpwrak>
it basically seems that *somewhere*, data and direction get swapped. (it's on the AVR, which uses only those two for H/L/R/Z) but this doesn't make sense. i even read back the whole mess, and it looks okay. except that it isn't :-(
<mth>
ah, it's not on the JZ
<wpwrak>
it's the atusb boundary scan. i send a pattern to the avr, it configures its gpios accordingly, then reports back all the registers involved. everything looks right, except the *somehow* direction and data end up being swapped. just how and where ? grmbl.
<wpwrak>
oh. i think i found it :) indeed, the only place where it's possible for a single bug to affect both setting and verification :)
<whitequark>
wpwrak: can you take a look at a circuit? one fellow said he has shorted a certain pin to GND and now it does not charge. For me, it looks like the LED backlight should have died instead :)
<whitequark>
the relevant parts are on page 3, the ones with VD1, VD2, VD3
<whitequark>
he shorted C17 to GND, and there was smoke
<wpwrak>
if there's smoke, perhaps he how has an excuse to buy the last issue of playboy ? ;-)
<whitequark>
that's not equally easy for everyone in Russia. some live quite far from the places you can buy playboy in
<whitequark>
anyway, I'm really curious why it could not charge now.
<whitequark>
that thing with VD2 (for everybody: 2R2 and a diode in series) is the ultimate chinese solution for charging Li-Ion batteries
<wpwrak>
yeah, i was looking for the charger. then it dawned on me that this contraption must be it ...
<wpwrak>
if the overcurrent blew 2R2 or VD2, that would explain the problem
<wpwrak>
you would only see a bcklight failure if L2 or VD3 had died
<wpwrak>
ah was the system on battery or USB power when it happened ?
<wpwrak>
(gpio scan) phew. just one misfit left. and that's the UART controller claiming control of the GPIOs
<whitequark>
wpwrak: I'll ask him. I think it was on batteries
<wpwrak>
also, how does he tell that the battery doesn't charge ? did he measure the battery voltage or did it just "not work" ?
<whitequark>
the firmware of player reads the voltage from ADC, and now it constantly says it's too low
<whitequark>
and then eventually it shuts off
<wpwrak>
so it could also be VT1 that's broken
<wpwrak>
or is that BAT_CTRL ? searching ...
<wpwrak>
ah yes. then it's directly the battery
<wpwrak>
yeah, my guess would be R9, VD2, or the battery itself
<wpwrak>
did he notice where the smoke came from ?
<whitequark>
wpwrak: when I've asked him whether the device was on USB or battery power, he answered twice, and on completely different question :/
<whitequark>
now he says that on USB it works, and on battery just shows white screen
<whitequark>
you're probably right
<whitequark>
wow, he posted that message (but in different words) third time
<wpwrak>
the smoke must have been traumatizing ;-)
<whitequark>
waits for the fourth
<whitequark>
bingo!
<wpwrak>
i wonder if the unexpected attention from the "wrong" clientele kinda killed that idea of making "intelligent ads"
<wpwrak>
hmm, i have a table where pin values can be - among others - "L" (that would be input low with a pull-up), "l" (input low without pull-up), and "1" (output low). l and 1 are hard to distinguish. any suggestions for an letter/symbol for either ?
<wpwrak>
(other characters in the table are "H", "h", "Z", "z", "1", "x", and ".")
<wpwrak>
and =, :, !, / are reserved. as are all shell meta-characters
<rjeffries>
wpwrak consider using zero 0 as symbol to represent input low w/o pull=up
<wpwrak>
ah, zero is taken as well. forgot to mention that one. "0" is output low.