<qi-bot>
[commit] Werner Almesberger: prod/doc/flash.html: use local copy of atusb-programming.jpg; language cleanup http://qi-hw.com/p/ben-wpan/889757e
<qi-bot>
[commit] Werner Almesberger: prod/doc/Makefile: moved %-front.png up to give priority over atben-%.png http://qi-hw.com/p/ben-wpan/e88d66e
<wpwrak>
(jzboot) that code snippet in the patch posted recently on the list looks rather scary. did this things originate from some obfuscated C contest ? ;-)
<xiangfu>
kyak, working on that now. (so many things :)
<kyak>
wpwrak: beware, the author is here :)
<kyak>
xiangfu: i'm not pushing, just good to know it's not forgotten :)
<whitequark>
wpwrak: what snippet? I didn't see it :)
<whitequark>
I probably should finally pack it the proper way
<wpwrak>
kyak: even better ;-)
<kyak>
whitequark: that would be great.. plus, reading the mailing list :)
<wpwrak>
whitequark: the patch by Ignacio Garcia Perez. CFGOPT and NOPT, which he cleaned up a bit, look like excellent candidates for helper functions (i.e., just put the invocation into a macro, leave the rest in the function). macros are hard to read.
<whitequark>
ah yes, i've subscribed
<whitequark>
there is an interesting improvement, now it is possible to load linux kernel ELF (the vmlinux) directly, passing the initrd and command line to jzboot
<whitequark>
like grub
<xiangfu>
kyak, you are using "xburst-tools_201002"? not 201012?
<kyak>
xiangfu: the "old" one i'm referring to is xburst-tools_0.0+201002-1_i386.bin.tar.bz2
<xiangfu>
kyak. ok. got it
<kyak>
so far, i have usbboot and usbboot_old in my path.. I changed reflash_ben.sh to flash bootloader with usbboot_old. However, usbboot_old checks if i'm root and exits if i'm not :) So i have to run reflash_ben.sh as root anyway
<xiangfu>
kyak, you can usbboot-201002 usbboot-201103, then one symlink :), no needs change reflash_ben.sh
<kyak>
xiangfu: i like the "reset" command in latest usbboot
<kyak>
it's not avialable in usbboot-201002
<xiangfu>
kyak, that is the only one I changed.
<xiangfu>
:)
<kyak>
xiangfu: can you reproduce this problem?
<xiangfu>
kyak, doing that now.
<xiangfu>
kyak, I know this bug before. it's hard to catch. when you reflash twice, the error will gone.
<qi-bot>
[commit] Ignacio Garcia Perez: FIXED: values of CPUSPEED greater than 255 were misread because the value was directly read into handle->cfg.cpu_speed (uint8_t) before dividing it by the external crystal frequency, and overflow resulted. Now intermediate variable is used and only the final result of the division is placed in handle->cfg.cpu_speed. http://qi-hw.com/p/jzboot/1cfb149
<xiangfu>
the jzboot is a git-submodule in xburst-tools.
<mth>
ah, I thought it was a standalone tool
<mth>
it does work when I compile it from xburst-tools
<whitequark>
mth: have you tested it on any hardware?
<mth>
xiangfu: building as part of xburst-tools works, thanks
<mth>
whitequark: yes, with Dingoo A320
<mth>
I have a config file for that if you're interested
<qi-bot>
[commit] Xiangfu Liu: usbboot: fix hand.fw_args.cpu_id have wrong value when there is no 'boot' in commands http://qi-hw.com/p/xburst-tools/1d7a2f3
<xiangfu>
kyak ^ this commit should fix the problem. just found the root cause.
<xiangfu>
kyak, thanks for bring this issue up :D
<kyak>
xiangfu: heh, ok, good thing i haven't yet got home to test :)
<xiangfu>
kyak, sure, take your time
<wolfspraul>
"root cause found" - always sounds great to hear that! :-)
<kyak>
and even greater when it's not some person :)
<qi-bot>
[commit] Werner Almesberger: prod/doc/hmac.pl: updated copyright; cleaned up declaration of local variables http://qi-hw.com/p/ben-wpan/838b8e1
<qi-bot>
[commit] Werner Almesberger: prod/doc/hmac.pl: allow self-referential macros (not general recursion) http://qi-hw.com/p/ben-wpan/2386f1f
<qi-bot>
[commit] Werner Almesberger: prod/doc/Makefile: added "spotless"; cleaned up generated/downloaded/orig logic http://qi-hw.com/p/ben-wpan/77a60a9
<whitequark>
qi-bot: why don't you reply when I PM you?
<whitequark>
heh
<larsc>
qi-bot: why don't you walk away?
<larsc>
hm, so no auto response on 'why don't you *'
<DocScrutinizer>
qi-bot: help
<DocScrutinizer>
qi-bot: status
<DocScrutinizer>
qi-bot: info
<DocScrutinizer>
qi-bot: owner
<DocScrutinizer>
qi-bot: author
<DocScrutinizer>
qi-bot: ?
<DocScrutinizer>
MEH!
<whitequark>
DocScrutinizer: try !help
<DocScrutinizer>
meh, how am I supposed to know about ! at all?
<DocScrutinizer>
qi-bot doesn't reply to any of the standard means a bot is supposed to identify itself, it doesn't tell about its master, and /ns info qi-bot shows [Notice] -NickServ- Flags      : HideMail
<DocScrutinizer>
according to freenode standards it had to get kickbanned
<wpwrak>
DocScrutinizer: afaik, asimov's laws say nothing about identification :)
<DocScrutinizer>
that's freenode's law however
<DocScrutinizer>
freenode is rather clear about bots
<DocScrutinizer>
rule #1: there has to be an easy way to contact bot master, when bot misbehaves
<DocScrutinizer>
s/when/in case/
<DocScrutinizer>
rule #0: bots mustn't join channels without allowance from chanop or chan owner (well that's not aplicable here I think)
<DocScrutinizer>
rule #2: if a bot misbehaves on e.g rule#0 and you can't raise the concern due to bot violating rule#1, kickban it before it does anything odd
<DocScrutinizer>
as I'm aware qi-bot is set up by chanowners, I'm just mentioning it here
<DocScrutinizer>
freenode staff might think and act differently ;-)
<DocScrutinizer>
and freenode staff might take a look faster than you might think, just consider qi-bot having some minor issues with authentication at either freenode or nameserv. Some staff might notice, take a look, realize there's no hint about whom to contact about it, and BANg
<DocScrutinizer>
even kline
<whitequark>
wpwrak: the 4th law "a robot should identify himself as an electronic creature" may have some sense :)
<wpwrak>
hmm, the justification for Lyuben Dilov's 4th law seems rather weak
<DocScrutinizer>
found this while digging thru the shallows of internet for freenode policy about bots: http://freenode.net/channel_guidelines.shtml - not exactly to the point but a rather instructive read I missed to reread for too long
<whitequark>
wpwrak: who's Lyuben Dilov?
<whitequark>
ah, yes, that's exactly what I suggested for 4th law
<larsc>
qi-bot: are you a robot?
<whitequark>
the interesting philosophical question: must a robot identify itself as a robot if it cannot recognize the question?
<whitequark>
i.e. it technically cannot identify itself "in all cases"...
<whitequark>
or, thinking from the other side, the nick "qi-bot" may or may not already carry the message
<wpwrak>
whitequark: perhaps it should just mutter "i'm a robot. i'm a robot. ..." all the time, just to err on the side of safety.
<wpwrak>
whitequark: (nick) good point !
<whitequark>
wpwrak: what if you didn't know English? its muttering then would be useless for you
<wpwrak>
the law doesn't say that it has to be useful. hmm. perhaps it would be sufficient if the robot would just silently emit a radio message.
<whitequark>
I suggest encoding it with different neutrino's
<wpwrak>
or modulate dark energy appropriately
<whitequark>
if you'd place a small synchrotron inside, and change beam targets in a certain pattern, you will easily generate the signal
<whitequark>
or you can go further
<wpwrak>
gravity waves. much easier. move a nano-scale object. even a very very very small mass has gravity.
<whitequark>
let's represent the robot itself as a quantum system (of course it is). then we make it very cold, in which case it becomes a single system
<whitequark>
grr, I don't know enough fancy terms to explain that.
<wpwrak>
perhaps you're referring to a BEC ? not sure if this works for non-gaseous robots
<wpwrak>
(Bose–Einstein condensate)
<whitequark>
wpwrak: probably not. I was talking about a state of several quantum particles (electrons are commonly used), in which case they share some common something, and altering an internal state of one also changes the state of others in a predictable way
<whitequark>
in russian it is called ":20=B>20O 70F5?;5==>ABL", but my dictionary does not know that.
<whitequark>
BEC surely has to do something with it, but it is different AFAIK
<larsc>
in german it probably is: quanten verschraenkung
<xMff>
quantum entanglement ?
<wpwrak>
entanglement
<wpwrak>
yup
<whitequark>
oh yes
<whitequark>
I've just understood that in order to free MSC0 on my board I can solder off the NAND which shares the pins
<whitequark>
can ingenics boot from MSC1?
<whitequark>
I'd like to use 4-bit MSC0 for an SDIO card
<larsc>
you can only use msc0 for booting
<wpwrak>
can the 4720 boot from MMC at all ?
<larsc>
no
<larsc>
only jz4750 and better
<larsc>
s/better/later/
<whitequark>
larsc: okay. then, can I connect two cards to MSC0? a brief look at PM suggests they can use different CS's
<whitequark>
I'm talking about "supports up to 10 cards"
<larsc>
you'd need a mmc multiplexer for that i guess
<wpwrak>
ah, you're talking about some other chip. i was already wondering where that MSC1 came from ;-)
<whitequark>
wpwrak: mine device has jz4725B==jz4750L
<whitequark>
*my device
<whitequark>
larsc: how do you think, will an SDIO WiFi card work in 1-bit mode?
<whitequark>
without the other 3 lines at all
<larsc>
for sdio you need at least two lines
<larsc>
i think
<larsc>
one for data and one for interrupts
<whitequark>
crap.
<whitequark>
can't it work in polled mode?
<larsc>
not sure
<whitequark>
I don't want to buy a $50 sdio card just to discover it is not supported at all
<larsc>
hm, the spec says "May be used Interrupt...."
<whitequark>
I'm flashing u-boot and kernel on nand, then it boots, turns off nand, turns on MSC1, uses it as root, then uses msc0 as it wants
<larsc>
could work
<larsc>
are all ADDR pins in use?
<larsc>
A15 and A16 are the default pins for address and command latch, but you could easily use any other pins aswell
<larsc>
i hope
<larsc>
but you also need FRE_ and FWE_ :/
<larsc>
hm, in their reference design, they also multiplex nand and mmc0
<whitequark>
ADDR...
<whitequark>
do I need them at all? I'm satisfied with root just on mmc1
<larsc>
i thought you wanted to use msc1 for sdio?
<whitequark>
if I could use msc1 for sdio, I won't muck with nand/msc0 then
<whitequark>
I'd just boot from nand
<larsc>
right
<whitequark>
msc1 is cut on 4725b, and only has 1 bit of interface => probably no sdio
<whitequark>
but sd storage works fine
<larsc>
according to the jz4725b specs i have all four data lines are available
<whitequark>
then I may turn off NAND and use the pins for MSC0
<larsc>
D28-D31
<whitequark>
well, they are probably present on the die
<whitequark>
but there are no physical pins.
<whitequark>
ingenic specs are writtten in... a very special way
<larsc>
copy'n'paste style
<whitequark>
yeah
<whitequark>
I dumped three days searching that pins :/
<wpwrak>
copy over a noisy channel, injecting errors :)
<larsc>
so the best option is probably to put a bootloader on the nand, which turns the nand off and switch the pins to mmc mode
<whitequark>
yeah, that's what I'll try
<whitequark>
I think that it will be enough to add proper msc0 initialization to linux
<whitequark>
the nand appears to be off (i.e. cs is high) when it is not used (read/written)
<whitequark>
I probably should still clear NFCSR, through
<whitequark>
ah yes, it has an option of asserting CE all the time or only during access periods
<whitequark>
wpwrak: that's a perfect anti-competitor trick. of course, if you don't think of it being anti-customer too...
<wpwrak>
whitequark: i guess some of the copycats would just copy the bugs as well ;-)
<whitequark>
bug-compatible hardware: sounds great
<whitequark>
at least you can keep existing workarounds
<whitequark>
(there was an old joke: if you learn from your mistakes, you don't do old errors. instead, you do absolutely new and unknown, and much more disastrous errors)
<whitequark>
it's exactly the case.
<wpwrak>
yeah. much better to make plenty of old errors, so nobody notices the new ones ;-)
<whitequark>
congrats, you've just defined The First Rule Of Chinese Hardware Development
<kristianpaul>
0_o
<whitequark>
kristianpaul: well, at least that applies to my device very well
<LunaVorax>
The news are full of questions
<LunaVorax>
Sony working on the PS4 for exemple
<LunaVorax>
what the heck seriously ?
<LunaVorax>
Isn't the PS3 powerfull enough ?
<LunaVorax>
Oh and Skype is becoming more and more closed.. as expected ;)
<whitequark>
literally
<wpwrak>
LunaVorax: (skype) the microsoft touch of death. like nokia.
<LunaVorax>
wpwrak, haha
<kristianpaul>
lol
<LunaVorax>
Too bad, at least we still have jabber/xmpp
<LunaVorax>
But I was keeping the hope of seeing an open-source client for skype one day
<GNUtoo>
someone must reverse engineer skype I guess
<GNUtoo>
that's ultra hard tough
<GNUtoo>
even harder than normal reverse engineering
<whitequark>
and they'll sue you
<GNUtoo>
why?
<whitequark>
at least they will try
<GNUtoo>
there is DCMA exceptions for interoperability
<GNUtoo>
and you could have layers too like SFLC
<whitequark>
reverse engineering skype is against its license agreement, isn't it?
<GNUtoo>
s/you/the person reversing it/
<GNUtoo>
yes, no problem, don't accept the license agreement
<LunaVorax>
GNUtoo, hummm maybe I should give it a try on my iTouch 2G but I don't know what to except/do with it.
<LunaVorax>
Oh wait, it's not compatible yet with my device :/
<whitequark>
larsc: on my board, NAND CS1 and CS2 are wired to CE1 and CE2 of flash chip, but I don't see any references to CS switching in the driver
<GNUtoo>
expect no suspend
<whitequark>
how do you think, can I connect whatever I want to CS2, assuming the default asserted is CS1?
<whitequark>
oh wait, that's my driver.
<wpwrak>
roh: which sw tools did you use for the MM1 case ? qcad ?
<grunthus>
Hi, I'm having a problem when powering on my Ben Nanonote:
<grunthus>
The display doesn't usually activate. Discovered tonight that ping response is OK and I have ssh'd in.
<grunthus>
So "the lights are off, but someone is home"
<grunthus>
Any experience with similar issues anyone?
<wpwrak>
grunthus: what does "usually" mean ? does it sometimes activate ?
<wpwrak>
grunthus: if the display always stays dark, this could be a problem with the cable connecting the LCD display to the bottom half of the device. let's hope this isn't the case :-)
<wpwrak>
grunthus: also, how long did the device power on normally before starting to exhibit problems ?
<grunthus>
wpwrak: I got the device from new last week. Problems powering on since day 1.
<grunthus>
The power on button never brings LCD up. Always have to do something with reset/remove battery etc.
<wpwrak>
grunthus: hmm. but eventually, it does turn on ?
<grunthus>
(Usually means I can get the LCD to come on after some combination of reset/battery out)
<grunthus>
let me just try a reboot via ssh
<wpwrak>
when you get the LCD to turn on, will it keep on working for a while ?
<grunthus>
yes, indeed, it will stay on until I turn the Ben off.
<grunthus>
In fact, I was going to ask how to get it to go into powersave mode, but this problem is more pressing.
<wpwrak>
interesting. doesn't sound like the cable then. more like a problem initializing the LCM.
<grunthus>
Not responding to ping now after reboot, will try reset switch again
<wpwrak>
afaik, powersave/suspend isn't very well supported at the moment
<wpwrak>
if it doesn't respond, maybe just try pushing POWER for a bit
<wpwrak>
(1-2 seconds)
<wpwrak>
it can sometimes end up in some undead state where it doesn't properly reset, but the power button will bring it up
<grunthus>
No response via power button.
<grunthus>
Additionally, it is no longer listed via lsusb
<wpwrak>
let's try this: remove the battery. disconnect USB. wait 20 seconds. then connect USB.
<grunthus>
OK, reset button causes device to show up in lsusb
<grunthus>
and ping response is back
<wpwrak>
(reset) good. so that works, too :)
<wpwrak>
but no display ?
<grunthus>
nope
<grunthus>
you mentioned LCM before?
<wpwrak>
you should be able to cycle the ben as follows: press POWER, wait a few seconds, the press POWER and hold it for about 1 second.
<wpwrak>
let me give you more exact numbers ...
<grunthus>
OK
<wpwrak>
assuming it's on: press POWER. it should then turn off within 5 seconds. press and hold POWER until the screen comes on (should take ~3 seconds). the system will be fully up about 30 seconds after pressing and holding POWER.
<grunthus>
it is on just now, i'm ssh'd in. About to try your procedure above...here goes
<wpwrak>
/sbin/reboot -f  from SSH should also cycle it reliably
<wpwrak>
if it's a hardware problem, it could be that the LCD cable only gives contact intermittently. but then i would expect that the display also fails from time to time when it's up and running.
<wpwrak>
so the symptoms are a little strange.
<grunthus>
The power has cycled. SSH/PING dropped on poweroff. Power on 3sec, ping and ssh'd back in.
<grunthus>
No LCD
<grunthus>
will try the /sbin/reboot -f cycle
<grunthus>
No joy, SSH OK, no LCD.
<wpwrak>
the problem may be stochastic in nature. i.e., the same procedure may sometimes work and sometimes not. to analyze this, we'd first have to find out what makes it more or less likely to happen
<wpwrak>
i.e., try each method a few (~5) times before switching to the next
<grunthus>
OK, I'll do /sbin/reboot -f repeatedly
<grunthus>
Thanks for helping
<wpwrak>
no problem :) too bad wolfgang isn't around. he knows all the little quirks best.
<wpwrak>
i'd try the following three cycling processes:
<wpwrak>
1) the reboot -f you're doing now
<wpwrak>
2) the power button
<wpwrak>
3) remove the battery; unplug usb, wait 30 s; connect USB; wait until the system comes up; repeat (if the system doesn't come up within ~30 s, press POWER)
<wpwrak>
if none of these yields anything, then there may be a mechanical component. you could try gently shaking the ben, then repeating one of the three methods a few times. if it still doesn't work, shake the ben again, etc.
<grunthus>
OK. I have run number 1) 5 times. Same behaviour
<wpwrak>
if all this gets too boring, maybe just leave it completely powered down (no battery, no usb) for an hour or so, then connect USB
<grunthus>
Sure, it might get boring. I notice that the ethernet over USB seems to die but ifconfig on desktop system can be used to reestablish connection straight away. Probably nothing related
<wpwrak>
if the problem has a mechanical component, it may be one of these two: 1) the connector into which the LCD cable slides is not properly locked. this could be repaired by opening the ben, properly placing the cable, then locking the connector. 2) the cable is broken (hairline crack or such). this isn't repairable.
<wpwrak>
both kinds of problems have happened, although (luckily) not very often
<grunthus>
Power button certainly works. Ping stops very quickly on press.
<wpwrak>
(power button) there's nothing as reassuring as a power button that works well ;-)
<grunthus>
No change with method 2)
<wpwrak>
let's hope for method 3 then
<grunthus>
No change on 3 either.
<grunthus>
system log shows usb device dis/connect appropriately
<grunthus>
If I try reseating the LCD cable, will that invalidate warranty, opening case.
<wpwrak>
it shouldn't ... where did you get your ben from ? directly from sharism ?
<grunthus>
it's from tuxbrain
<wpwrak>
hmm, dunno what his policy is. maybe mail him ? in general, nobody should complain if you open the device. but i can't speak for tuxbrain :)
<grunthus>
Will do. Perhaps he will prefer me to send it back.
<wpwrak>
ah, here's wolfgang. just in time :)
<wpwrak>
wolfspraul: you'll be happy - we have a support case. lcm acting up on a new device. only sometimes activates. most of the time doesn't.
<wpwrak>
wolfspraul: he already tried all the usual ways of power-cycling several times, to no avail. so it seems there's a mechanical component in the problem.
<grunthus>
wolfspraul: hi, I'm the case!!
<wpwrak>
wolfspraul: the device is from tuxbrain. should he (grunthus) try to open the ben and see if he can re-seat the cable ? or do you have any other things he could try ?
<grunthus>
wpwrak: do you mind if I mention you in email to David Samblas (tuxbrain)
<wpwrak>
grunthus: sure. he knows my name well enough ;-)
<wolfspraul>
grunthus: ah hi!
<grunthus>
Thanks, I have asked if I can open it.
<grunthus>
hi
<wolfspraul>
I was about to reply to you on the forum, but now you are here :-)
<wolfspraul>
on the forum you said it worked with the reset button?
<grunthus>
It has done, but not today.
<wolfspraul>
is it an LCM problem or mechanical issue with the power button?
<wolfspraul>
when you press the power button, hold it for a good long 5 seconds or so, just in case
<wolfspraul>
don't press too hard, just long
<grunthus>
The power button seems to cycle the power properly, I can see log messages on my desktop system relating to usb device
<wolfspraul>
but the screen remains dark?
<grunthus>
and I can watch ping response
<grunthus>
dark, yes.
<grunthus>
On the occaisions when reset press has activated the LCD it works reliably
<grunthus>
for hours on end, lid open/shut, no problems.
<wolfspraul>
it may be an issue with the fpc (flexible printec circuit, a thin cable) running from the mainboard under the keys to the lcm
<wolfspraul>
it goes to the lcm on the right side, where it says 'mic'
<grunthus>
wpwrak thouhgt that
<wpwrak>
wolfspraul: btw (other topic), have you heard of Linaro ? http://www.linaro.org/
<wolfspraul>
wait grunthus first
<wolfspraul>
it's possible that the fpc doesn't sit tight in the connector anymore
<wpwrak>
wolfspraul: they're a sw house, but with ties to hw.
<wpwrak>
(sure)
<wolfspraul>
if it is not connected at boot time, it may miss some initialization of the lcm module
<grunthus>
what does FPC abbreviate?
<wolfspraul>
a thin cable (flexible printed circuit)
<grunthus>
ahh.
<wolfspraul>
I'm still thinking whether our analysis is correct
<wolfspraul>
but yeah, I think so
<grunthus>
is there anything in /proc which would allow me to query the LCD in some way?
<wolfspraul>
good question, probably only larsc would know
<wolfspraul>
for the Ben, I'm sorry for the inconvenience but yeah, it looks like we need to replace it and give you a new one
<wpwrak>
wolfspraul: (analysis correct) i also suspect the cable
<wolfspraul>
sure I know linaro
<grunthus>
Thanks for helping.
<wolfspraul>
it's an attempt of arm ltd. and the arm ecosystem to pump money (and engineering resources) into cleaning up ARM support in linux
<wolfspraul>
grunthus: can you try to press with your finger where the 'mic' label is?
<wpwrak>
(replace) could grunthus perhaps try open the ben and reseat the cable ? in case it's just a case of the connector not being properly locked
<wolfspraul>
sure he can try, but because it's his first time he may end up with a device that has a few scratches
<wolfspraul>
even if it then works
<wpwrak>
wolfspraul: (linaro) ah, not quite what we need then. i wonder if they may have contacts that could help us, though ?
<wolfspraul>
grunthus: no worries we had such cases before (unfortunately), and if you contact tuxbrain it will be replaced without a fuss
<grunthus>
pressure around mic area - no response on LCD
<wolfspraul>
by now we had maybe 10 such cases
<grunthus>
wolfspraul: can I mention your name if I email David Samblas?
<wolfspraul>
from about 1200-1300 nanos sold
<wolfspraul>
of course you can, why not?
<wpwrak>
~1%. did you do a post-mortem on them to see if it's connector or cable ?
<grunthus>
less than 1% then.
<wolfspraul>
50% cable reseating helps, 50% the connector on the mainboard side has a soldering problem, i.e. resoldering it helps
<wolfspraul>
I don't remember that we've had an issue with the heat-printed connection under the lcm (on the other side of the cable)
<grunthus>
I think I saw an article (on BBC?) about VGA via SD slot which led me to the Nano, I bought one within an hour of reading the article.