<oofoe>
Hi! Quick question... I had a LOVE program crash and lock the SDL screen.
<oofoe>
All black, nothing showing. I'm still logged in through ssh but I don't see any process
<oofoe>
to kill and get my framebuffer back. What should I do? Thanks!
<oofoe>
BTW, this is for the NanoNote...
<wpwrak>
oofoe: seems that you'll have to await the return of the maker of love ... (or just reboot :)
<oofoe>
I think he's asleep... ; - )
<oofoe>
I just thought someone else might have run into the problem another way.
<oofoe>
However!
<oofoe>
I have learned how to turn off the LCD backlight from the shell...
<oofoe>
You can echo a "1" into /sys/class/lcd/lcd_power (I think that's it (I've switched screens right now)) to turn it off.
<oofoe>
"0" turns it on...
<oofoe>
Whee!
<wpwrak>
kewl. now you can use the ben as a flashlight :)
<oofoe>
Apparently, you can use "fbgrab /sys/class/framebuffer/fb0" (or something like that (I switched screens again!)) to get a screen cap.
<oofoe>
This sys stuff is very interesting... When I was first using UNIX, we didn't have any of this...
<oofoe>
There appear to be several fb* tools in /usr/bin...
<wpwrak>
(fb0) isn't there one in /dev, too ?
<wpwrak>
yeah, /sys is somewhat inspired by what sun did on solaris, but with a ton more things added. the new place to dump stuff, after /proc got too messy ;-)
<oofoe>
Yeah, there's the /dev/fb0, but the sys stuff seems more intended for monitoring and control.
<oofoe>
I guess like /proc...
<wpwrak>
yes, and /sys also provides the raw data for /dev
<wpwrak>
anyway, the evil day star will be up soon. time for me to crawl to bed ...
<oofoe>
Quick question before you go... Is there an equivalent of fuser installed on the machine?
<oofoe>
I thought I could find who has the lock on /dev/fb0 so I could kill it to reset things, but no fuser...
<oofoe>
Oh, well, I have my own day star to face in about five hours. Probably a good time to call it off...
<wolfspraul>
you probably saw that I committed the --plot stuff, and exit code fixes
<wolfspraul>
so I think next I will bring some reports/files live on the server, meaning that I automatically generate them upon commits
<wpwrak>
ah, exit code, yes. tested it. works great ! thanks !
<wpwrak>
haven't played with --plot yet. but if schhist is happy, then i guess it works :)
<wolfspraul>
how about the cmdline options now?
<wolfspraul>
do you need more?
<wpwrak>
for now, i'm more than satisfied with the ones we have :)
<wolfspraul>
ok
<wolfspraul>
I need to start communicating with upstream at some point, to make the patch more maintainable.
<wpwrak>
you probably already saw that i automated most of the process for atusb. CAM and toner transfer are done. only the BOM is missing.
<wpwrak>
(upstream) yup :)
<wolfspraul>
no I haven't seen it yet
<wolfspraul>
too many things
<wolfspraul>
but it sounds great! very nice...
<wpwrak>
this should do the trick: cd ben-wpan/atusb/cam2; make
<wpwrak>
then you can "make cng", "make drill", "make mill"
<wpwrak>
well, it won't do much without a mill, but at least the mechanisms are all there
<wpwrak>
and in ben-wpan/atusb itself, "make front" and "make back" print the respective sheets for toner transfer
<adamw_>
wolfspraul, I got no replies after typing "gtkterm -p /dev/ttyUSB1 -s 115200"
<wolfspraul>
adamw_: try this: unplug jtag-serial. run "tail -f /var/log/syslog" on your computer (as root). then connect the jtag-serial again.
<adamw_>
Jan  3 18:37:54 adam-laptop kernel: [13245.600186] usb 6-1: USB disconnect, address 3
<adamw_>
Jan  3 18:38:46 adam-laptop kernel: [13296.953092] usb 6-1: new full speed USB device using uhci_hcd and address 4
<adamw_>
Jan  3 18:38:46 adam-laptop kernel: [13297.095148] usb 6-1: not running at top speed; connect to a high speed hub
<adamw_>
Jan  3 18:38:46 adam-laptop kernel: [13297.117387] usb 6-1: configuration #1 chosen from 1 choice
<wolfspraul>
do you see a new entry in lsusb?
<wolfspraul>
btw, in the Windows reflash tool, did you also create a random serial number?
<adamw_>
ID 20b7:0731 by lsusb
<wolfspraul>
in "Hardware Specific, Port A, Hardware", you need to change from RS232 UART to 245 FIFO
<wolfspraul>
at least that's what my notes say
<adamw_>
no , i didn't create a serial number.
<wolfspraul>
ok, that shouldn't matter
<wolfspraul>
how about the change from RS232 UART to 245 FIFO?
<adamw_>
wait
<wolfspraul>
it seems your Linux machine does not create /dev/ttyUSB devices, don't know why
<wolfspraul>
unfortunately I don't have a board here so I cannot try/compare
<wolfspraul>
try this: lsusb -v -d 20b7:0731
<wolfspraul>
it should list a lot of data, don't paste it here but upload it to pastebin.com
<adamw_>
it can not be detected in FTDI FT_Prog utility, so i can't see if the change from RS232 UART to 245 FIFO.
<wolfspraul>
he. maybe because you switched the vid/pid?
<adamw_>
yes, i think.
<wolfspraul>
go back to Linux and try that lsusb -v -d command
<adamw_>
upload to pastebin.com?
<wolfspraul>
yes
<yizhang>
my nanonote always disconnects from my machine after 10, 20 seconds after i connect it to my PC. does any of you had such problem and how did you fix it?
<wolfspraul>
have you tried that before? it's fun...
<yizhang>
any suggestion would be greatly appreciated.
<wolfspraul>
I remember something on the list about that.
<adamw_>
wolfspraul, never used pastebin.com  , just try...second
<adamw_>
but i used F5(scan) the FT_Prog didn't see it?
<adamw_>
well...let me try anther new pod.
<lekernel>
this problem is explained in the FT_Prog documentation and you should either disable the EEPROM temporarily (so the cable reverts to its default IDs) or modify the driver's INF file to use the new IDs
<wolfspraul>
lekernel: hmm, but your device class is also still 'vendor specific'
<wolfspraul>
for the serial shouldn't there be some serial device class?
<wolfspraul>
adamw_: when you flash again, remember changing "Hardware Specific, Port A, Hardware" from RS232 UART to 245 FIFO
<lekernel>
the other usb/serial cables I have here also use "vendor specific" class
<wolfspraul>
at least that's what I did and it worked well
<wolfspraul>
adamw_: on the windows side, you should edit the .inf file to add both 20b7:0713 and the (wrong) 20b7:0731 - then you can easily use FT_Prog when needed
<adamw_>
the 20b7:0713 in *.inf is correct, just I typed wrong in FT_Prog program. :)
<wolfspraul>
yes but now you need to add the wrong one so you can fix that one board
<wolfspraul>
that sounds easier than disabling the eeprom
<wolfspraul>
connect the board directly to your notebook, not to an external hub
<wolfspraul>
I'm still surprised about the high-speed thing, let's see :-)
<lekernel>
that's the most troubling issue so far
<lekernel>
but maybe it's only a hub/port/cable problem
<adamw_>
in windows, it can show "Milkymist USB JTAG
<adamw_>
" & "Milkymist USB Serial
<adamw_>
"
<wolfspraul>
let's focus on Linux
<adamw_>
i know why  I got wrong. I just changed the wiki page from "0731" to "0713"...man
<adamw_>
yeah..
<wolfspraul>
the PID should not matter that much for your testing right now
<wolfspraul>
did you connect it directly to your notebook before? or to a hub?
<adamw_>
direct to notebook.
<wolfspraul>
ok where are you now? did you change the PortA/Hardware thing to 245 fifo?
<adamw_>
yes
<wolfspraul>
what does Linux say in /var/log/syslog when you connect the board?
<wolfspraul>
tail -f /var/log/syslog
<adamw_>
new full speed USB device using uhci_hcd and address 10
<adamw_>
Jan  3 19:29:25 adam-laptop kernel: [16336.119151] usb 5-2: not running at top speed; connect to a high speed hub
<adamw_>
Jan  3 19:29:25 adam-laptop kernel: [16336.143386] usb 5-2: configuration #1 chosen from 1 choice
<wolfspraul>
adamw_: run 'dmesg' and paste the last 20 lines or so in pastebin.com
<wolfspraul>
how many external USB connectors does your notebook have?
<wolfspraul>
right now the jtag-serial board seems to be connected to a 1.1 hub
<wolfspraul>
so is a Logitech mouse
<adamw_>
three ports
<adamw_>
i typed 'ls /dev/ttyUSB1' to each port after I plugged
<kristianpaul>
adamw_: did you tried type also dmesg after you pluged (to get a better debug) ?
<adamw_>
all not detected jtag-serial
<wolfspraul>
one by one
<wolfspraul>
maybe the board just works fine
<adamw_>
kristianpaul, YES
<wolfspraul>
I keep saying that I don't know why Linux would detect the ttyUSB device. earlier lekernel seemed to say that if it's not detected as high-speed, then it won't setup the ttyUSB?
<wolfspraul>
but I wouldn't know why
<adamw_>
i didn't see any like 'attached to /dev/ttyUSB0 or /dev/ttyUSB1'
<wolfspraul>
so maybe we have 2 problems right now:
<wolfspraul>
1) your notebook does not have external usb 2.0 (high-speed) ports
<wolfspraul>
maybe all 3 external ports are 1.1
<wolfspraul>
2) it is not clear (to me) how Linux detects the ttyUSB devices, whether that can only work in high-speed
<wolfspraul>
worst case we run the whole test in Windows
<adamw_>
so for 1) how can we easily make sure my linux laptop built with 2.0 (high-speed)?
<wolfspraul>
it is 'built', but not sure about the external connectors
<wolfspraul>
you have 3, right?
<adamw_>
yes, 3 ports
<wolfspraul>
1 has the jtag-serial now, another one has the logitech mouse, right?
<wolfspraul>
how about the 3rd one. move the jtag-serial from where it is now to the 3rd one.
<wolfspraul>
(the empty one)
<wolfspraul>
then pastepin lsusb -v again
<adamw_>
the others two I unplugged
<wolfspraul>
before when you ran lsusb, you had jtag-serial and logitech connected
<adamw_>
ok....let me do three times again with only jtag-serial
<wolfspraul>
move jtag-serial to the one that was _not_ used by jtag-serial or logitech before
<wolfspraul>
we already know that the port you had jtag-serial before, and logitech before, are both 1.1
<wolfspraul>
so you only need to try the 3rd one
<adamw_>
now..i was confused...so let me do each usb port and pastebin.com
<wolfspraul>
which appeared in 2.6.32-25 (and you are on -27, very close)
<adamw_>
hmm..ok
<wolfspraul>
maybe scrap Linux and just test on Windows
<wolfspraul>
I have no board here, I cannot effectively help you debug it.
<wolfspraul>
you have no known-good board either, and were not able to prepare for the testing in advance.
<wolfspraul>
you already can verify the serial port in Windows, the only thing that remains is a quick jtag test
<adamw_>
yeah..
<wolfspraul>
not sure you have full-speed or high-speed in Windows
<adamw_>
but all linux commands depends on device name, isn't it?
<wolfspraul>
I don't have complete overview.
<wolfspraul>
the vid/pid is quite important
<wolfspraul>
and I think the 'interface class' too, but that may be wrong already
<wolfspraul>
the strings should not be important, but who knows, someone may also look at those
<wolfspraul>
when you reflash, remember to set the iManufacturer, iProduct and iSerial strings
<wolfspraul>
for the iSerial, just let FT_Proc create a unique/random number
<wolfspraul>
iManufacturer = Qi Hardware
<wolfspraul>
iProduct = Milkymist One JTAG/serial
<wolfspraul>
you can check with lsusb -v -p 20b7:0713, the boards you are making should look like http://pastebin.com/AwjFCH5x
<wolfspraul>
except that the iSerial should be unique on each board
<wolfspraul>
also back when I flashed them, in FT_Prog I set this "Hardware Specific, Port A, Hardware" from RS232 UART to 245 FIFO
<wolfspraul>
I suggest you only flash and test 20 now.
<wolfspraul>
that's enough
<wolfspraul>
no need to waste time with the other 80, since we will most likely fine-tune this setup, looking at the confusion we are facing right now :-)
<adamw_>
yeah..i can sure I did a unique/random number in FT_Proc
<wolfspraul>
just play around a little
<wolfspraul>
we don't know much, and have few boards to compare with/debug
<wolfspraul>
maybe when lekernel is back he can correct some of our assumptions...
<wolfspraul>
from what you see in Windows, it seems that flashing works, and serial works too
<wolfspraul>
that's a good sign
<wolfspraul>
just need to find a way to check jtag from Windows
<adamw_>
yeah...I'll try to reflash Manufacturer name
<wolfspraul>
and maybe see whether the board is recognized and operating in high-speed mode
<wolfspraul>
I pasted a link to some free software above, maybe that helps.
<adamw_>
also maybe I directly use xilinx tool to test if jtag function is ok
<wolfspraul>
on Linux?
<adamw_>
on windows
<wolfspraul>
hmm
<adamw_>
but I didn't try...before
<wolfspraul>
not sure it works, there may also be problems in recognizing the board
<wolfspraul>
maybe if you flash the vid/pid to be the same as in the xilinx cable it can work?
<adamw_>
so need to check somewhere document is
<wolfspraul>
there are quite a few switches and settings, and ftdi variants...
<wolfspraul>
I think it's messy anyway, we are not well prepared. So just find whatever way you think the boards are working. serial and jtag.
<wolfspraul>
only test 20.
<wolfspraul>
then we need to improve this whole process in Linux
<wolfspraul>
(later)
<adamw_>
ok...
<wolfspraul>
you tested serial already, just need to find a way to test jtag :-)
<wolfspraul>
with serial working, I'd say things look good
<wolfspraul>
I'm an optimist...
<adamw_>
yeah...via Tera Term Pro, it works well
<adamw_>
well...i try my self to find if using xilinx tool in windows to test jtag.
<wolfspraul>
I can imagine that the xilinx tool will look for specific pid/vid numbers.
<adamw_>
once I success in window and read Spartan 6 id back then the jtag/serial run should be all fine
<wolfspraul>
so unless you reflash the jtag-serial boards with the vid/pid usb ids that the xilinx software expects, it may not work with the jtag-serial board
<wolfspraul>
of course I'm guessing
<wolfspraul>
or maybe you can tell the xilinx software somehow to accept 20b7:0713
<wolfspraul>
and to understand that it is a ftdi 2232 with jtag on port a
<adamw_>
but I still feel strange why my linux laptop is 1.1 not 2.0
<wolfspraul>
the 2.0 is internal
<wolfspraul>
the external connectors (seem) all to be 1.1
<wolfspraul>
the notebook is 4 years old, right?
<adamw_>
hmm....i checked official web...it said
<wolfspraul>
what notebook model is it?
<adamw_>
ha...bad...it's really 2.0 internal only
<wolfspraul>
btw - I really think the low-speed high-speed discussion is besides the point.
<wolfspraul>
according to the 2232 datasheet the chip should support both
<wolfspraul>
so there are more configuration issues on the Linux side, not just low-speed
<adamw_>
V1020 model , Fujitsu
<wolfspraul>
both serial & jtag _should_ work with low-speed as well, I think
<adamw_>
hmm...I'll check 2232 jtag/serial circuit again tonight
<wolfspraul>
it works in Windows
<wolfspraul>
I'd focus on that
<adamw_>
well...i need to have dinner now,
<adamw_>
see you later
<wolfspraul>
enjoy
<adamw_>
thanks a lot!
<kristianpaul>
arggg openmoko support for wikireader sucks :(
<wolfspraul>
why?
<kristianpaul>
The wikireader i have to my mother for chrismas jsut got bricked
<kristianpaul>
I debug my self the SD card and seems dead, no fdisk, no dmesg recognize it
<kristianpaul>
I write that to OM support
<kristianpaul>
They first askme to do silly procedure of taking SD & Batterues back and put it again
<kristianpaul>
Now i reply with a: i dint work
<kristianpaul>
please tell how to debug SD, i *bought* a bran new SD from kingstone
<kristianpaul>
They reply: ok, send us the device back to Sandiego, CA, we can see what was wrong with it..
<kristianpaul>
bah
<kristianpaul>
Thats 50usd i'm not going to pay more for it, i already pay around 160USD just to have in holliday
<zrafa>
kristianpaul: better would say to buy two nns and work on better wikireader for it :)
<zrafa>
would say= would be
<kristianpaul>
zrafa: my mother is not good with keyboards..
<kristianpaul>
no good at all and no hope it will change
<kristianpaul>
I like the wikiriader i have from you btw :-)
<zrafa>
kristianpaul: you could disable several keys on nns, so it looks like OM wikireader :)
<kristianpaul>
lol
<kristianpaul>
any way i formally close this off-topic chat, sorr for the noise i was a bit biased and angry
<wpwrak>
DocScrutinizer: (OVP and USB 2.0) high-speed is a pain, yes. but full-speed is a lot more relaxed. and the components are cheaper, too. TVS are quite pricey for what they are.
<DocScrutinizer>
yep
<wolfspraul>
we have sorted out the jtag-serial stuff in the #milkymist channel
<wolfspraul>
"modprobe ftdi_sio vendor=0x20b7 product=0x0713" did the trick
<wolfspraul>
all moving now :-)
<wpwrak>
DocScrutinizer: (happy new year) you too ! :)
<DocScrutinizer>
:-D
<wolfspraul>
DocScrutinizer: Dieter didn't make it to 27c3 either in the end, he got snowed in.
<DocScrutinizer>
ooh
<wpwrak>
zrafa: (usb 2.0) its a bit more complex. usb 1.0, usb 2.0, etc. are the versions of the standard. then you have low-speed, full-speed, high-speed, and soon yet another thing (don't know what they called it - "insane speed" perhaps ? :)
<wolfspraul>
super speed?
<wolfspraul>
:-)
<wpwrak>
zrafa: now usb 1 only defined low and full speed. usb 2 defines everything in usb 1 plus high-speed
<wpwrak>
zrafa: so if a product says "usb 2.0", it can still be only high- oder even low-speed. needless to say, this is rather confusing.
<kristianpaul>
hmm confusing indeed
<wpwrak>
wolfspraul: (usb 1.1 vs. usb 2.0 hub) do you know that, if you have a EHCI (the high-speed controller), that you also have an OHCI/UHCI (low/full-speed) in parallel ?
<wpwrak>
wolfspraul: (usb) the EHCI only does high-speed. if your device is something else, it gets rerouted to the UHCI/OHCI
<wpwrak>
wolfspraul: so it seems unlikely to me that thus 4 yo laptop would only have 1.1 ports on the outside. possible explanations for not detecting a high-speed device as high-speed would include: 1) kernel somehow not configured to support it (not terribly likely with ubuntu, but you never know), 2) some odd bios setting that disables the EHCI, 3) some mystery bit in the FTDI that makes it not ask for high-speed, or 4) some hardware flaw t
<wpwrak>
hat makes high-speed negotiation fail.
<wpwrak>
wolfspraul: did adam try to insert a usb flash stick ?
<wolfspraul>
I don't think so.
<wolfspraul>
we have put this high-speed thing aside for now.
<wolfspraul>
I thought he googled that his notebook indeed only has usb 1.1 on the outside?
<wolfspraul>
don't worry about it. maybe he needs to buy a new notebook anyway, and then switch to fedora right away...
<wpwrak>
the tricky bit with using different machines is that sometimes your problems come from the capacitative load. e.g., the first atusb boards had TVSs of 330 pF on the USB lines. they worked flawlessly with my PC and my fujitsu laptop. then i connected them to the OQO a few days ago. lo and behold, they didn't even enumerate.
<wpwrak>
of course, 330 pF is way too high. (what's allowed are 50 pF) after removing those little monsters, the boards worked fine.
<wpwrak>
(i used those 330 pF critters, because a) i hadn;t foung the limit back then (it's a bit hidden in the standard. they write a lot about low-speed and then even more about high-speed, but the full-speed load limit is conveniently placed only in the caption of a figure), and b) becasuse i had hoped to make the board easily diy-makeable :)
<wpwrak>
wolfspraul: another issue with the ftdi chips: their horrible lack of documentation makes linux support unreliable, particularly when it comes to the eeprom utility (ftdi_eeprom). it's not so bad for the really old chips, but more recent ones can have issues. e.g., with the FT232RL, the default use set an endpoint size to zero, so the chip would enumerate, but any attempt to send bulk data with libusb would fail, with the kernel compla
<wpwrak>
ining that the message was too large.
<wolfspraul>
I know. We are working on making all of this work flawlessly out of the box, but it will take some time.
<wpwrak>
wolfspraul: so your approach of trying with the official windows tools first has some merits (i guess you didn't expect me to say that :)
<wpwrak>
well, or at least s/windows/proprietary/
<wolfspraul>
yeah well. this jtag-serial run is a little less organized than normally anyway.
<wolfspraul>
I am gambling that the board is so simple that not much can go wrong :-)
<wolfspraul>
so I sent all 3 working boards to Sebastien, leaving 0 for Adam. That would be a total no-no for any normal product.
<wpwrak>
(not much can go wrong) about one month if fighting the ft232rl taught me otherwise ;-)
<wolfspraul>
essentially Adam has to make 100 of a totally unknown board (for him), right away. No testing preparations, just make them then find out whether they work :-)
<wolfspraul>
yes I know, it's risky. I am crossing my fingers.
<wolfspraul>
Sebastien needed his 3. If Adam would have had one the last month or so things would be much more controlled.
<wolfspraul>
but this way, they are more fun :-)
<wpwrak>
do sebastien's work ?
<kristianpaul>
yes
<wolfspraul>
it'll be fine.
<wpwrak>
yeah the boards aren't too expensive, so it's not too big a gamble, i guess
<wolfspraul>
next time we raise the standards a little.
<wolfspraul>
in a way, at least the lowering of standards was on purpose / controlled. controlled chaos...
<wpwrak>
if sebastien got his three to work, then the chances of adam eventually succeeding should be rather good :)
<wolfspraul>
oh of course
<wolfspraul>
those boards worked even before I sent them to sebastien
<wpwrak>
"controlled flight into terrain" (-:C
<wolfspraul>
the board was designed by Yanjun Luo
<wolfspraul>
and he soldered (by hand!) 4 of them
<wolfspraul>
they all worked
<wolfspraul>
he kept 1, gave me 3
<wpwrak>
aah, so the 3 are not from the same batch as adam's. i see.
<wolfspraul>
after consideration, I decided to give all 3 to Sebastien, even though it was risky on Adam's side
<wolfspraul>
that's why Adam is scramling (a little) right now
<wolfspraul>
no not at all. the pcb was made elsewhere, the sourcing was elsewhere.
<wpwrak>
you should have bribed yanjun to make one more :)
<wolfspraul>
crystal was changed, headers were changed, one usb bug (high-speed related :-)) was fixed
<wolfspraul>
and then 100 right away, and first time for adam to ever have a working one in his hands
<wolfspraul>
this is not the right way to do things, I know. but whatever. some tough decisions here...
<wolfspraul>
at least it's a global collaborative project
<wpwrak>
yeah. i known to be good unit would have helped adam at least with the host software side
<wolfspraul>
sure
<wpwrak>
but well, no risk, no fun :)
<wolfspraul>
we decided against it ;-) (sorry Adam...:-))
<wpwrak>
and adam's learning experience will be more profound ;-)
<wolfspraul>
wpwrak: I see adam slowly developing hardcore foss survival techniques, like 'when in doubt what to do in a directory, just run make and see what happens'
<wolfspraul>
if he continues down that road, he will be really good in a while :-)
<wpwrak>
hehe :)
<bartbes>
have you guys seen the clock oofoe made?
<bartbes>
(I believe he called himself oofoe1 here)
<zrafa>
zear: because you was a bit tired and frustrated with your nn and broken screen
<zear>
zrafa, my screen is fine if i don't wiggle with it
<wpwrak>
zear: if your host is 64 bit, then you may need some small tweaks to make it work. but once it works, it's very comfty
<zear>
wpwrak, nah, it's x86
<wolfspraul>
oh good point. that sdk I pointed to is 64-bit.
<zear>
wpwrak, i don't remember the exact error i was getting, but the same error with dingux toolchain meant the toolchain was placed in the wrong path
<zear>
but we've double checked with rafa and everything seemed to be correctly installed
<wolfspraul>
so you have a 32-bit system?
<zear>
wolfspraul, yes, a 32 bit gentoo
<wpwrak>
zear: maybe just try rafa's latest and see if it works now ?
<wpwrak>
zear: one of the nice features is that you can install .ipkg packages into your build environment. so if you need some exotic library, you just install the -dev package and you're good.
<zrafa>
zear: again.. the old one worked for me because my local settins. But the toolchain was not properly built. SO forget that. We tried to fix that one because we did not have the proper one (which we have now)
<zear>
zrafa, sounds great now
<zear>
i'll check it out sooner or later
<zrafa>
wolfspraul: the xiangfu link you put here looks like xiangfu did the same mistake like me to prepare a sdk or toolchain
<zear>
wpwrak, i prefer a "non-interactive" kernel where i don't need to use any package managers to install extra apps
<zrafa>
wolfspraul: I will try to talk him about.. it should not have a hardcoded DIR or local settings from his environment
<zear>
and where i can do just export PATH="${PATH}:/path/to/my/toolchain" and not play with any weird commands like with the openmoko toolchain ;)
<zrafa>
wolfspraul: I did the same, and now check how tired is zear after to try with me to use a bad toolchain
<zrafa>
:)
<zear>
zrafa, i basically have some other stuff to do for today ;)
<zear>
i'll try it out in the near future though
<wpwrak>
zear: huh ? are you seriously claiming packages are a bad thing ?
<zrafa>
zear: no problem, I have not with a lot of time either
<zrafa>
zear: so just try whenever you want
<zear>
wpwrak, no, but i like when you have everything in your toolchain already and you don't need to worry about installing extra packages
<wpwrak>
zear: doesn't have much to do with the kernel, by the way
<zear>
because sooner or later you'll break your toolchain with some dependencies you downloaded from the repo :D
<zrafa>
zear: well, but we can not put all the 15.000 packages on toolchain
<wolfspraul>
wpwrak: does the background change after --bom bother you a lot?
<zear>
wpwrak, i meant non-interactive toolchain, sorry ;D
<zrafa>
better if we install them when we need
<wolfspraul>
if not I will just wait a little and see what accumulates. I have seen this one but wasn't alert enough to investigate on the spot.
<wpwrak>
zear: well, the toolchain has the basics. but there's just too much stuff around for an installation of everything to make much sense. besides, some things probably conflict with each other in some ways.
<zear>
zrafa, i know, i guess i'm just used to gaming devices' toolchains, where all you need can be fit in a ~50M toolchain file
<zrafa>
zear: and we can add stuff with just a command (with opkg-target). It is really easy.
<wpwrak>
wolfspraul: only until i find out how you managed to make this happen ;-) (it's easy to revert - change the preferences. even if you don't save them, they "stick". more magic.)
<wpwrak>
wolfspraul: (saw it) good. so it's not just some local quirk :)
<zear>
btw zrafa, what was miriam's eeepc's model?
<wolfspraul>
it's probably saved automatically
<wolfspraul>
I am not surprised
<wolfspraul>
there are so many load and save config calls all over the sources, unbelievable
<wpwrak>
sigh. it's just a little odd that it also auto-saves if you have a "save" button right there
<wolfspraul>
I am setting the background to black. I probably need to be more diligent, find out where it's saved, and then revert to the original value at the right time.
<wolfspraul>
not surprised. from looking at the sources the config stuff is really messy.
<wolfspraul>
lots of defaults, overrides, read, write, etc.
<wpwrak>
zrafa: how big is your package repository ? ;-)
<wolfspraul>
in some places they even reload because they don't trust what's in memory...
<wpwrak>
;-)))
<wolfspraul>
let's just accumulate a few more bugs then I'll fix them in one go
<wolfspraul>
if you want it fixed, let me know
<wpwrak>
btw, why do you set the background to black when generating a BOM ?
<wpwrak>
(fixed) yeah, no hurry
<wolfspraul>
good point, just a bad flow
<wolfspraul>
I just need to look into it, no problem other than time.
<wolfspraul>
I'm most concerned about maintenance overhead when upticking KiCad, that will be interesting.
<zrafa>
zear: eeepc 900
<zrafa>
zear: I guess that asus does not make it anymore
<zear>
zrafa, i bought exactly the same model then :D
<zrafa>
zear: haha.. :D
<zear>
and if it wansn't for the meeting, i probably wouldn't decide to purchase one
<viric>
anyone tried to use fbreader?
<zrafa>
zear: we are using linux mint there.. really nice and fast
<zear>
i really liked the size factor and how it presents in general
<zear>
zrafa, i'll remember to bug you a bit about it once i get it in mail
<zear>
the one i bought (secondhand) comes with xandros preinstalled
<zrafa>
zear: that sucks (xandros)
<zear>
but the seller was so nice to call me and apologise for the preinstalled linux, assuring me i can reflash to xp in no time ;D
<zrafa>
zear: warning: I think that there is a tiny really tiny fat partition (maybe 5mb). dont delete that one
<zear>
zrafa, what would happen if i did so?
<wpwrak>
is xandros upstream still around ? i think the eebox or whatever it is called i got for my tv also had xandros. couldn't even update the distro :)
<zrafa>
zear: it is really OT, we can continue at jlime or private :)
<zear>
sure ;)
<wpwrak>
zrafa: now that we all are curious about what happens ;-)
<zrafa>
wpwrak: haha :D
<zrafa>
wpwrak: repositoy: I guess that around 15000 packages :)
<wpwrak>
zrafa: any idea how many MB ? ob kinda curious how it relates to zear's 50 MB
<zrafa>
wpwrak: xandros: the eeepc just let you install pacakges from some asus repo IIRC, few packages and xandros really sucks for me
<wpwrak>
s/ob/i'm/
<zrafa>
wpwrak: zear's 50 MB is a toolchain for linux game consoles.. which brings with SDL, allegro, etc.. libraries used by games
<zear>
zrafa, not allegro, i failed to properly port it
<wpwrak>
hmm, there's a bug in boom's price selector. if picking a part X that also satisfies the requirements for part Y, then it'll use X for both, even if there was a cheaper choice for Y. something to fix in the rewrite ...
<kristianpaul>
yay seems i finally i'm not getting repeated data in a common pattern
<wpwrak>
with the ring buffer ?
<kristianpaul>
well i dint changed that part of the code
<kristianpaul>
Actually i just modified the C code was polling data
<kristianpaul>
It was pointing a fixed address now i points the whole 1024 registers in secuence
<wpwrak>
ah. so what did you change then to make it work ?
<kristianpaul>
That make me thing if want go back to fixed pointe i should do more test with the timing setup on the (SMCR
<kristianpaul>
wpwrak:Â Â i replaced a constant with a for loop
<wpwrak>
eek :)
<wpwrak>
maybe try to get help from the people who have been working with SIE in the last months ? maybe they already know the problem or have solved it
<kristianpaul>
I need clen more stuff i wanted to confirm my theory of exotic timing tune in the Xburst EMC
<kristianpaul>
well.. there is an already solution
<kristianpaul>
but not compatible with ring buffer
<kristianpaul>
cause it requires start a reading, wait it finish, then read the collected data and start again..
<kristianpaul>
kind of slow for what i'm looking (stream gps raw data as it arrives)
<kristianpaul>
Well i already wrote to qi list with cc to carlos, and dint get other replies besides the one you can see :-)
<kristianpaul>
Anyway i'm learning a lot with all this issues :-)
<kristianpaul>
s/issues/ignorance from my side
<wpwrak>
maybe ask a bit more specifically, e.g., whether any of carlos's students has done something similar. then poke that guy.
<kristianpaul>
The ADC is the most similar
<kristianpaul>
and it works as i already pointed
<wpwrak>
the fragile timing doesn't sound good. if you don't solve this early, you'll never be able to trust your results.
<kristianpaul>
They still need a IRQ glag implemented as a register
<kristianpaul>
yeah, i need trust my results indeed
<kristianpaul>
i alredy send one to be analized i'm hoping get results back soon
<wpwrak>
i'd still kinda suspect caching. but the symptoms don't match exactly
<kristianpaul>
I'll do few more test i think i'm close
<wpwrak>
e.g., i would expect the cache to almost never change, since you're probably in a very tight loop with a small working set
<wpwrak>
but then, maybe you're not. in which case the cache could be pretty erratic.
<kristianpaul>
hmm
<wpwrak>
kristianpaul: have you checked that the memory region into which the FPGA is mapped is uncached ?
<wpwrak>
i think a quick indicator should be to see if the region is listed in /proc/iomem
<kristianpaul>
no
<wpwrak>
to access the FPGA, do you mmap /dev/mem ?
<wpwrak>
or do you have some dedicated device in /dev ? or maybe some library that handles the mapping for you ?
<kristianpaul>
yes (/dev/mem)
<kristianpaul>
wpwrak: how i can know if it is cached?
<wpwrak>
hmm, a little suspicious. i wonder what cache settings the kernel defaults to when nothing specific is set
<wpwrak>
maybe let's try something else first
<wpwrak>
can you write to the FPGA, or only read ?
<kristianpaul>
write to
<kristianpaul>
s/to/too
<wpwrak>
okay, then maybe try this: disable the writing. i.e., when you read you get X, then you write Y but the value is not stored. then the next read should yield X again.
<kristianpaul>
ok let me try
<wpwrak>
(i hope :) all depends a bit on how the xburst handles such things, but it would be the "usual" way for uncached memory)
<wpwrak>
larsc: what do you think ?
<larsc>
what to i think about what?
<wpwrak>
for finding out how whether caching is set, the only way i can think of is to walk the page tables. but that's messy. what your drivers normally do is just request the right kind of caching and you trust the kernel to do it right.
<larsc>
is the fpga connected to the memory bus?
<kristianpaul>
larsc: it shares addr and data, so yes it is
<wpwrak>
larsc: whether this test for caching would work on xburst: read read-only location X getting value Y, write Z != Y to X, then read X again. if you get Y, there's not cache. if you get Z, the CPU is caching the data.
<larsc>
well if you mmap the uncached address it should work
<wpwrak>
larsc: ah, uncached address ... that's an architecture detail i have to look up then :)
<larsc>
KSEG1 is the keyword
<kristianpaul>
I dint get not Y either Z, so it should be okay
<larsc>
kristianpaul: what is the address which mmap?
<wpwrak>
neither Y nor Z ? that's scary ;-)
<kristianpaul>
0x15000000
<kristianpaul>
wpwrak: is not, well i dont changed the fpga, let me hardcode the reg ;-)
<larsc>
kristianpaul: i think thats cached. 0xB5000000 is the uncached address
<wpwrak>
larsc: should that be 0xb5000... ?
<wpwrak>
hah ! :)
<larsc>
hehe
<kristianpaul>
ah
<kristianpaul>
wait wait i'll set a read-only-reg on fpga first
<kristianpaul>
larsc: how do you know that is cached?
<kristianpaul>
and how wpwrak point the right address ?
<larsc>
because it is in kseg0 and kseg0 is cached
<larsc>
to get the uncached address from an cached address you have to OR it with 0xa0000000
<wpwrak>
kristianpaul: and, did the result of your program change ?
<kristianpaul>
wait wait my cpu still is do syhtesis right now
<kristianpaul>
wpwrak: i get Y
<wpwrak>
very good ! :)
<wpwrak>
larsc: high five, i think ;-)
<kristianpaul>
but i was mapping 0x15000000
<wpwrak>
kristianpaul: grrr.
<larsc>
could be luck
<kristianpaul>
wait, i'll try 0xB5000000
<larsc>
better use 0xb5...
<wpwrak>
yeah, caches have a lot in common with schroedinger's cat
<kristianpaul>
i'm not used to systems with MMU. i see why i never tought in that...
<lekernel>
cache controllers with bug too. but they're nowhere near as bad as USB
<wpwrak>
lekernel: having a fight with USB right now ? :)
<lekernel>
used too... getting it to work on MM1 was an horrible experience
<lekernel>
USB and SDRAM were the two worst things to fight with
<lekernel>
but at least SDRAM was interesting, I learned a lot
<wpwrak>
hmm, this is fun. one of my disks is failing. (or maybe it's the mainboard - that pc had some issues before) meanwhile, the program is happily running, collecting data with nowhere to save it. this will be fun :)
<lekernel>
and there are still some USB bugs it seems...grr
<lekernel>
they only happen with certain devices, of course
<lekernel>
mine work correctly
<wpwrak>
the joy of interoperability :)
<wpwrak>
"certain devices" = certain MM1 or certain things they connect to ?
<lekernel>
certain things they connect to
<lekernel>
the MM1 USB hardware is simple enough not to have board-to-board variations (except poor solders joints, we had that too)
<wpwrak>
that's the evil part, yes
<kristianpaul>
hmm are you sure about 0xb500? my Xbusrt is jz4725
<kristianpaul>
I said cause i'm not reading what is on sra-on-fpga..
<wpwrak>
kristianpaul: they should be all the same
<kristianpaul>
hmm :/
<wpwrak>
are there any readable SIE schematics ?
<wpwrak>
(the ones in schhist are undecipherable)
<larsc>
kristianpaul: it works with 0x1500... but not with 0xb5000..., thats strange. can you show the code?
<qi-bot>
[commit] Werner Almesberger: atusb/usb.sch: typo in VR1 footprint, should be 0402 instead of 0403 http://qi-hw.com/p/ben-wpan/04d3cec
<qi-bot>
[commit] Werner Almesberger: atusb/usb.sch: typo: the LED is called LTST-C190KRKT, not LTST-C190KTKR http://qi-hw.com/p/ben-wpan/882558b
<qi-bot>
[commit] Werner Almesberger: atusb/usb.sch: specified capacitance of TVSs (33 pF) and explained why http://qi-hw.com/p/ben-wpan/08eec5b
<qi-bot>
[commit] Werner Almesberger: atusb/atrf.sch: changed C3, C8, C9 to "22pF/RF", to make BOOM select UHI Q type http://qi-hw.com/p/ben-wpan/9851e3c
<qi-bot>
[commit] Werner Almesberger: tools/lib/atusd.c (atusd_open): open /dev/mem with O_SYNC to disable caching http://qi-hw.com/p/ben-wpan/f26d735
<wpwrak>
@^&#$%&^$!^$&
<viric>
it looks like a bad configured serial port.
<wpwrak>
Digi-Key Part Number AT86RF230-ZU-ND, Ship Date Estimate (mm/dd/yyyy) 4/13/2011
<wpwrak>
someone just snatched up all the chips they had in stock :-(
<wolfspraul>
oh oh
<wolfspraul>
:-)
<wolfspraul>
hardware is fun
<kristianpaul>
indeed, i just fixed my wikireader too, seem the SD was fucked (dunno why happen this), so i will not recomend to buy "Team" branded micro SD/HC cards
<wpwrak>
interestingly, the AT86RF231 is stocked all over the place
<wpwrak>
the only problem with it is that, last time i checked, it was a non-export item
<lekernel>
wpwrak: where do you live btw?
<wpwrak>
in buenos aires, argentina
<kristianpaul>
Any one can explain me for this: mmap (0, FPGA_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, address);
<kristianpaul>
What is about PROT_READ and PROT_WRITE, ?
<wpwrak>
this means that you can read and write to those registers
<kristianpaul>
ah ,pitty :-)
<kristianpaul>
tk
<wpwrak>
hmm. i could order the at86rf231 without problem. maybe they lifted the ban.
<wpwrak>
even better then. the 231 is slightly better. should be basically 100% compatible.
<wpwrak>
yeah. the TI chip (CC2520) is still restricted, but the 231 is now orderable. phew :-)
<kristianpaul>
"FFT of a gps signals shows almost nothing except lots of noise, but if you have a very large gain before the antenna or a observatory antenna (like ESA or NASA) you can see the CDMA spectrum of GPS signal."
<kristianpaul>
oh well better i avoid it :-)
<kristianpaul>
So i'll jump to PRN matching just  (yay), but first lets fiinsh debuging the data acquisition :-)
<wpwrak>
did switching to volatile help to make the fpga access more reliable ?
<kristianpaul>
ah yes i did voaltile
<kristianpaul>
I got almost same patter (data repeated twice)
<kristianpaul>
I'm just tracking/fixing a posible error i had defining some pointers ;-)
<wpwrak>
nice. the 231 doesn't need an external input to enter test mode. this makes a few things easier. (one i/o can be removed from atusb and i don't have to hack one into atusd. wasn't looking forward to the latter at all.)
<wpwrak>
(almost same pattern) :-(
<larsc>
why are mircoprocessors banned from importing?
<wpwrak>
transceivers. and they're banned from exporting, not importing
<wpwrak>
apparently because they contain AES
<wpwrak>
bad, bad excryption
<larsc>
i see
<wpwrak>
"if we let this fall into the wrong hands, the terrorists win" or the commies. or whatever ;-)
<wpwrak>
well, seems that atmel got it cleared, while ti (with a similar chip) didn't
<wpwrak>
heh, and they also added a - probably highly proprietary - high data rate mode in the new chip :)
<wpwrak>
up to 2 Mbps. WLAN, here we come ! ;-)
<wpwrak>
good. and they relaxed the frame retrieval timing. you still lose a frame if you're too slow, but it at least doesn't (partially) overwrite the old frame.
<wpwrak>
and this means that i'll have to wait until the new chips arrive before making the new boards. good that i haven't started yet. but with some luck, i can keep the layout. (will be slightly sub-optimal for the one trace i could remove now, but that's a very minor issue)
<wpwrak>
kewl. digi-key already processed my order. their speed is just crazy.
<DocScrutinizer>
hmm, NFC would interest me more
<DocScrutinizer>
and RFID in general
<wpwrak>
too near :)
<wpwrak>
hmm, the local-es list looks like another of these traps, where people can go thinking something is happening - but nothing is. interesting stats: http://lists.en.qi-hardware.com/pipermail/local-es/
<kristianpaul>
tuxbrain around to get a quote...
<kristianpaul>
I bet some of then just swiched to english list
<wpwrak>
yeah. the community is far from being big enough to need language-specific sub-communities.
<wpwrak>
speaking of ghost towns, wolfgang: http://sharism.cc/ -> "News". maybe call them "Oldies" ? ;-) all the rest on that page is also kinda scary. one could think that everybody just caught the swine flu and died several months ago
<kristianpaul>
yes
<kristianpaul>
If you have troubles with this website please notify webmaster [at] sharism.cc . :p
<kristianpaul>
I guess is jsut usefull to pay by cc ;-)
<kristianpaul>
is getting cold here ~20 °C
<wpwrak>
here too, only 25 C. i want my 30 C back !
<kristianpaul>
haha
<kristianpaul>
26 C should and some fresh air should be fine :-)
<wpwrak>
plenty of fresh air here, supposedly at 34 km/h (don't quite believe it)
<kristianpaul>
Are you watching the gnome applet for worlwide time/weather too ? :-)
<kristianpaul>
Amazing, so those guys relly desided not doing FFT on the FPGA and just then multyply and  do some serial seeking and  so on.. several times and with diffrent values in order to predict and for 11 channels !
<kristianpaul>
is LGPL gut i'll dig on it later seriosully
<kristianpaul>
the more fun of all is that they have a comercial vesion too, wich is sold with all the features that a MM SoC have !
<kristianpaul>
hehe
<kristianpaul>
wpwrak: i still getting two copies of data
<kristianpaul>
I'm starting to think that the refresh for the buffer is not so fast at all..
<wpwrak>
(gnome applet) no .. what's it called ?
<wpwrak>
(copies of data) :-((
<kristianpaul>
well is not an applet, sorry is just integrated with the default clock on latelly gnome versions
<kristianpaul>
I jsut dint knew how call it
<wpwrak>
ah, so you need their desktop. naw, that i don't want :)
<kristianpaul>
what do you use then?
<wpwrak>
grmbl. atmel had to introduce one change that makes the 230 pin-incompatible with the 231. couldn't resist, could they ?
<kristianpaul>
I like from gnome, the clock is always there, plus world time to track all of your  in differet place s is not bad
<wpwrak>
(desktop) fvwm as window manager, no "desktop"
<kristianpaul>
ah
<wpwrak>
for world time, i fire up kworldclock
<kristianpaul>
(atmel) oh yes they could :-)
<kristianpaul>
(kde) i cant talk about it i'm totally biased agains KDE :/
<kristianpaul>
s/talk/use
<wpwrak>
i use konqueror and kworldclock. not the rest. "desktops", no thanks :)
<wpwrak>
(pin-incompatible) i'm curious if that change is actually for real ...
<wpwrak>
now the fun part ... there are a few outputs they recommend connecting to ground if unused. now that's something that kicad's ERC really hates ...
<kristianpaul>
hmm
<kristianpaul>
more trouble then seems :/
<wpwrak>
ah, wind is picking up. we may still make those 34 km/h tonight
<wpwrak>
oh, i hacked some ERC exception mechanism some time ago. the kicad folks didn't like it, but it's in our patch set. time to use it :)
<kristianpaul>
34 km/h is really fast, do you have something to make move with that wind?
<wpwrak>
ah, the beagle-crossover. not the "real" gta04 :)
<kristianpaul>
ah
<wpwrak>
if i remember our numbering right, then gta04 was supposed to run in parallel with gta03, as an attempt to do more aggressive outsourcing. it was unceremoniously buried once the supposed outsourcers communicated their idea of an appropriate compensation :)
<wpwrak>
DocScrutinizer probably would remember the details better than i do