| 00:02.42 | *** join/#qi-hardware Jay7 (jay@78-106-209-136.broadband.corbina.ru) |
| 00:18.07 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 01:06.44 | pabs3 | DocScrutinizer: glamo docs are fully public now, Sean got permission to release them |
| 01:10.54 | pabs3 | (well, unless there are some he didn't have or forgot about) |
| 01:17.16 | kristianpaul | yes it is |
| 01:17.18 | kristianpaul | mplayer |
| 01:17.22 | kristianpaul | segfautls.. |
| 01:17.28 | kristianpaul | or. |
| 01:17.36 | kristianpaul | in my image.. |
| 01:22.49 | kristianpaul | Okay, confirmed i'll be there http://softwarelibre.info |
| 01:23.26 | kristianpaul | i was told have one hour... oh well, i'll carry my M1, nanonote and see what i can demo or talk, also give away some stickers etc.. |
| 01:23.44 | wolfspraul | nice! |
| 01:25.42 | kristianpaul | yeah.. well, i would like to spare time for more activities but :) |
| 01:26.23 | wolfspraul | who is the audience? |
| 01:26.23 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 01:27.05 | kristianpaul | students, mature people (who also pay tickets? btw..) |
| 01:27.30 | kristianpaul | i'm not very aware of FLOSS audience in the Ecuador so, all is new.. |
| 01:28.21 | kristianpaul | ah, i guess people from oter floss based enterprises as well.. |
| 01:43.23 | pabs3 | wonders if kristianpaul will take some opencores stuff too |
| 01:44.06 | kristianpaul | i take milkymist cores too ;-) |
| 01:44.25 | kristianpaul | but i dont want get too tech at leas is necesary, remenber is floss event.. |
| 01:44.36 | pabs3 | I meant http://opencores.org/ |
| 01:45.19 | wolfspraul | pabs3: have you developed for fpgas? which opencores cores have you found usable? |
| 01:45.35 | pabs3 | no |
| 01:45.48 | wolfspraul | I would love to understand better what is there and how to (re)use and improve it, but except for "hey there is opencores", typically there is nothing :-) |
| 01:46.03 | kristianpaul | indeed, i havent time to look at opencores, perhpas the ethernet and usb ones.. but ... nah to lazy to compare |
| 01:46.06 | pabs3 | given that Linux supports OpenRISC now, I guess something from there is working |
| 01:46.14 | kristianpaul | it works indeed |
| 01:46.31 | kristianpaul | and openrisc SoC is a fact for that |
| 01:46.35 | kristianpaul | indeed |
| 01:47.13 | wolfspraul | have either of you tried it? |
| 01:47.49 | roh | hey wolfspraul |
| 01:47.51 | kristianpaul | waiting stekern release its openrisc port to M1.. |
| 01:47.52 | roh | got my mail? |
| 01:48.01 | wolfspraul | kristianpaul: yep :-) |
| 01:48.06 | wolfspraul | that would be great |
| 01:48.18 | wolfspraul | pabs3: do you have a url for "linux supports openrisc"? |
| 01:48.31 | wolfspraul | who is using it? have they documented their work? |
| 01:48.50 | pabs3 | goes looking |
| 01:49.08 | wolfspraul | of course I know these statements for months, years. but a lot seems to be just hearsay. |
| 01:49.34 | pabs3 | wolfspraul: http://kernelnewbies.org/Linux_3.1#head-37c60fa1253db74ce7d224718a71f5836bd5be09 |
| 01:49.38 | wolfspraul | one-off experiments with lots of unresolved issues, barely enough for some bragging, no code releases, of course nobody else building on top of it because there is nothing to build upon :-) |
| 01:49.54 | wolfspraul | pabs3: let's find users and documentation |
| 01:50.04 | wolfspraul | that would help us and/or stekern |
| 01:50.18 | wolfspraul | if it's open and it works, anybody should be able to use it |
| 01:50.32 | wolfspraul | roh: yes, got it - thanks! |
| 01:50.54 | roh | wolfspraul: hope you can meet. nice guy (mitch) |
| 01:50.59 | kristianpaul | pabs3: fyi stekern is a guy at #milkymist that hack around openrisc and its SoC |
| 01:51.14 | wolfspraul | fact is this: |
| 01:51.48 | wolfspraul | milkymist soc runs today, and afaik nothing stops us from replacing the lm32 core with an openrisc core |
| 01:52.02 | wolfspraul | except for 'a little' work :-) |
| 01:52.10 | kristianpaul | little, ha ;) |
| 01:52.24 | kristianpaul | well.. |
| 01:52.33 | wolfspraul | but for some reason Sebastien says the lm32 core is superior, and there must be a reason for that |
| 01:52.45 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 01:53.05 | wolfspraul | and we should be careful to dismiss that simply reiterating statements from lots of people where most haven't even tried to use what they claim exists |
| 01:53.11 | wolfspraul | or: fire up your code editor :-) |
| 01:53.45 | wolfspraul | I also hear that opencores has a 'great' 'linux supported' usb controller |
| 01:53.46 | kristianpaul | lm32 has its advantages yes, plus still small and not bad documented i think |
| 01:54.45 | wolfspraul | I try to follow opencores with the best intention for years, read their newsletter, browse projects, etc. |
| 01:55.15 | wolfspraul | but somehow it doesn't translate into reality |
| 01:55.25 | wolfspraul | but let's see |
| 01:55.31 | wolfspraul | stekern is our hope |
| 01:55.58 | wolfspraul | and maybe pabs3 buys a m1 soon and starts opencores hacking |
| 01:56.33 | wolfspraul | it's one thing that a developer sayss "this works great", or 100 or 1000 users actually agree with him :-) |
| 01:56.40 | wolfspraul | that's an entirely different thing in my experience |
| 01:56.50 | wolfspraul | like night and day - *that* different |
| 01:57.24 | wolfspraul | pabs3: does this make sense? let's start to *use* opencores stuff! |
| 01:57.38 | pabs3 | indeed |
| 01:57.40 | wolfspraul | not just point to it, that's no news for years |
| 01:57.50 | wolfspraul | when we use it, we find out what really works |
| 01:57.54 | pabs3 | personally I don't have the time nor disposable income to start working on that though |
| 01:57.59 | wolfspraul | we find out the nasty little details that make all the difference |
| 01:58.05 | wolfspraul | sure sure |
| 01:58.11 | wolfspraul | I did not in any way want to dismiss your input |
| 01:58.21 | wolfspraul | maybe one day you find the time and excitement |
| 01:58.23 | pabs3 | understood :) |
| 01:58.29 | wolfspraul | opencores is great |
| 01:58.30 | wolfspraul | we all love it |
| 01:58.48 | kristianpaul | milkymist uses conbus core from it ! |
| 01:58.51 | wolfspraul | but so far I think not 1 line of any opencores core is running on m1 |
| 01:58.52 | wolfspraul | why? |
| 01:58.53 | wolfspraul | strange |
| 01:58.56 | wolfspraul | AH! |
| 01:58.57 | wolfspraul | there you go |
| 01:59.02 | kristianpaul | wich is the thing glue all soc comunication :) |
| 01:59.15 | wolfspraul | kristianpaul: do you have a url into the opencores site to the original conbus? |
| 01:59.20 | kristianpaul | sure |
| 01:59.23 | wolfspraul | I mean the one that m1 reuses/uses |
| 01:59.39 | wolfspraul | I want to build more of those connections, make people understand where things come from so they can find more... |
| 01:59.59 | kristianpaul | http://opencores.org/project,wb_conbus |
| 02:00.01 | wolfspraul | I repeatedly hear 'openrisc' and also 'usb controller' |
| 02:00.34 | kristianpaul | well, the version is not the same, but that one in milkmist re-use most of the code i remenber |
| 02:00.38 | wolfspraul | kristianpaul: how much was the code changed when being brought over to m1? |
| 02:00.46 | kristianpaul | 20-30% i bet |
| 02:00.52 | kristianpaul | havent dont full comparison |
| 02:01.19 | wolfspraul | that's the one thing in cores land that still confuses me |
| 02:01.27 | wolfspraul | how can people work together, and benefit from each others work |
| 02:01.39 | wolfspraul | is the m1 'fork' (?) of conbus known to the original conbus devs? |
| 02:01.43 | wolfspraul | do they care? |
| 02:01.52 | kristianpaul | i think i wrote him.. |
| 02:01.58 | kristianpaul | but never got reply.. |
| 02:02.02 | wolfspraul | are cores mostly a one-time heoric effort without much reuse or long-term value? |
| 02:02.12 | kristianpaul | then i find answer my self trought milkymist version ;) |
| 02:02.23 | wolfspraul | nice that you tried to establish contact |
| 02:02.27 | wolfspraul | no reply, oh well :-) |
| 02:03.04 | pabs3 | goes to idle on #opencores |
| 02:03.09 | kristianpaul | pabs3: also sebastien sent back to opencores some cores from milkymist, the memory controller and navre (usb soft core= |
| 02:03.12 | kristianpaul | pabs3: no no |
| 02:03.14 | kristianpaul | too alone :) |
| 02:03.18 | kristianpaul | really :) |
| 02:03.23 | wolfspraul | I think the typical 'open core' (not a pun on opencores) is buggy like hell |
| 02:03.42 | wolfspraul | there are too few devs |
| 02:03.46 | wolfspraul | no quality standards |
| 02:04.00 | wolfspraul | no standardized test environments |
| 02:04.28 | wolfspraul | no expectation of reuse even, which makes devs even more reluctant to invest their time in reusability |
| 02:05.07 | wolfspraul | too many subtle details in different fpgas, even fpga generations, asic |
| 02:05.34 | wolfspraul | timing optimizations that eventually lead to a magic binary bitstream that nobody will touch or dare to ask how on earth it was made |
| 02:06.18 | wolfspraul | buggy vendor toolchains working against any efforts for better long-term quality and reusability |
| 02:06.24 | wolfspraul | more? :-) |
| 02:06.28 | wolfspraul | kristianpaul: would you agree? |
| 02:06.47 | wolfspraul | you are out in the minefield for a while now... you probably know what I mean, or can tell me if I'm wrong |
| 02:07.10 | wolfspraul | testing in general is under-appreciated in open cores |
| 02:07.27 | kristianpaul | yeah i know.. :-| |
| 02:07.35 | wolfspraul | of course because a lot of the value of high-quality and repeatable testing only shows years later after someone reuses the core, which may be never, so nobody invests in that... |
| 02:07.52 | wolfspraul | actually the problem is not infinite, not at all |
| 02:07.54 | kristianpaul | also i followed opencores for while, until found you guys :D |
| 02:08.03 | wolfspraul | but there are *a lot* of shaky foundations right now, quicksand |
| 02:08.20 | kristianpaul | cores with a SoC. well... |
| 02:08.42 | wolfspraul | from a quality perspective, I think opencores is just a random assortment of all sorts of code snippets |
| 02:08.53 | wolfspraul | I think that's fair to say, althouhg I also don't know how to do better |
| 02:08.54 | kristianpaul | lets wait stekern news hopefully will give us better info about all this |
| 02:09.21 | wolfspraul | milkymist soc doesn't have the problem because there is 1 dev who tightly controls the entire soc tree - of course he can at least from his perspective keep the quality and testing up |
| 02:09.28 | wolfspraul | kristianpaul: definitely :-) |
| 02:09.38 | wolfspraul | but most likely stekern will run into lots of nasty details |
| 02:09.45 | wolfspraul | on the surface it looks easy, but then... |
| 02:09.52 | wolfspraul | will he work through all of them? why? |
| 02:10.17 | wolfspraul | maybe just a few quick hacks enough for a demo or to say 'it works', then move to greener lands? |
| 02:10.22 | kristianpaul | to benchmark, that 'boring' need to be done anyway no? |
| 02:10.32 | wolfspraul | it's a chicken-egg problem |
| 02:10.32 | kristianpaul | hehe it works hacks :) |
| 02:10.40 | wolfspraul | no culture of reuse |
| 02:10.45 | wolfspraul | no investment in resuability |
| 02:10.51 | wolfspraul | reusability |
| 02:11.05 | kristianpaul | fully agree, on that one |
| 02:11.21 | wolfspraul | so let's start to fix the culture first, of course we try to not just talk about 'open cores', but actually use them and fix all the nasty bugs |
| 02:11.29 | wolfspraul | and invest in high-quality documentation and testing |
| 02:11.38 | wolfspraul | until hopefully one day the real reuse and feed back cycle starts |
| 02:11.45 | wolfspraul | that's how I see it |
| 02:11.45 | kristianpaul | hmm may be we need first list SoC currently using wishbone and wishbone-like cores, plus compare what from opencores too |
| 02:12.08 | wolfspraul | would be good to do that on wikipedia though |
| 02:12.43 | wolfspraul | I'm editing milkymist-related information in wikipedia sometimes, as I learn. but could do more. |
| 02:13.10 | wolfspraul | there was also a port of milkymist soc to altera |
| 02:13.13 | wolfspraul | very exciting stuff imho |
| 02:13.43 | wolfspraul | but william (fpgaminer) also has a limited time budget and it's too hard to unite it back and say "milkymist soc is supported and tested on xilinx s-6 and xilinx s-3 and altera xxx" |
| 02:13.47 | wolfspraul | one code tree |
| 02:13.51 | wolfspraul | one set of documentation |
| 02:13.54 | kristianpaul | oh, i need to dollow the editing of that article more often |
| 02:14.03 | wolfspraul | would be cool, but lots of work and again: why do it? if nobody reuses anyway :-) |
| 02:14.04 | kristianpaul | s/dollow/follow |
| 02:14.05 | qi-bot | kristianpaul meant: "oh, i need to follow the editing of that article more often" |
| 02:16.35 | wolfspraul | lemme see, at least the url |
| 02:16.41 | wolfspraul | trying to build bridges :-) |
| 02:16.54 | wolfspraul | painful to build a bridge when nobody cares to use it anyway |
| 02:17.04 | wolfspraul | you rather just use a boat to cross the river once, for yourself |
| 02:17.06 | wolfspraul | much easier, right? |
| 02:17.49 | wolfspraul | here |
| 02:17.51 | wolfspraul | https://github.com/progranism/Open-Source-System-on-Chip-Experiment |
| 02:17.59 | wolfspraul | which Altera chip was this, one sec? |
| 02:18.16 | kristianpaul | cyclone III i bet |
| 02:18.42 | wolfspraul | great, can't even find in the README :-) |
| 02:19.08 | wolfspraul | and (*zero* blame to william here), there is not much effort to merge activities, or at least document/learn from each other |
| 02:19.28 | wolfspraul | in fact he already did me a great favor by publishing his sources, trying to arrange them a little like the milkymist soc tree, etc. |
| 02:19.34 | wolfspraul | that is already pioneering work! |
| 02:20.00 | wolfspraul | most people take an open core, tweak, polish, tweak more, hack, tweak, until it works. and then everything they learnt stays unstructured and locally and is not fed back. |
| 02:20.22 | wolfspraul | I think I must have seen this 10 times now with bits and pieces from milkymist, over the last 2 years. |
| 02:20.25 | wolfspraul | painful :-) |
| 02:20.27 | wolfspraul | so much wasted knowledge |
| 02:20.45 | wolfspraul | kristianpaul: you think cyclone III? |
| 02:21.56 | wolfspraul | seems he mentioned DE2_115 |
| 02:22.25 | kristianpaul | ah, thats cyclone II i remenber |
| 02:22.57 | kristianpaul | no no |
| 02:23.08 | kristianpaul | argh, anywyay |
| 02:24.01 | wolfspraul | what I find looks like Cyclone IV EP4CE115 |
| 02:24.36 | kristianpaul | oh much better |
| 02:24.55 | kristianpaul | he also i wodering now if he run on to routing problems.. |
| 02:24.58 | kristianpaul | need to as |
| 02:24.58 | kristianpaul | k |
| 02:25.13 | wolfspraul | wow that chip alone costs about 400 USD |
| 02:25.38 | wolfspraul | we have such great value on m1! |
| 02:25.52 | kristianpaul | ;) |
| 02:25.58 | wolfspraul | super high performance at low chip cost, and full focus on the open cores |
| 02:26.09 | wolfspraul | then we have noone but ourselves to blame :-) |
| 02:26.51 | wolfspraul | and the devkit sells for 300 USD :-) |
| 02:26.57 | wolfspraul | the de2-115 one |
| 02:28.19 | wolfspraul | I need to register/login with opencores to even view the sources? |
| 02:28.59 | wolfspraul | those kinds of things make me wonder about the platform, better move the sources to github even |
| 02:45.43 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 03:57.04 | *** join/#qi-hardware heyllo (~heyllo@wsip-70-183-103-105.sd.sd.cox.net) |
| 03:57.11 | heyllo | wassup |
| 05:03.40 | qi-bot | [commit] kyak: libcss: update to 0.1.2 (master) http://qi-hw.com/p/openwrt-packages/b53ab42 |
| 05:03.41 | qi-bot | [commit] kyak: libhubbub: update to 0.1.2 (master) http://qi-hw.com/p/openwrt-packages/18bd88f |
| 05:03.42 | qi-bot | [commit] kyak: libnsfb: update to 0.0.2 (master) http://qi-hw.com/p/openwrt-packages/a347d74 |
| 05:03.44 | qi-bot | [commit] kyak: libparserutils: update to 0.1.1 (master) http://qi-hw.com/p/openwrt-packages/e0300a0 |
| 05:03.46 | qi-bot | [commit] kyak: libwapcaplet: update to 0.1.1 (master) http://qi-hw.com/p/openwrt-packages/e1e92f2 |
| 05:03.48 | qi-bot | [commit] kyak: libnsbmp: initial port (master) http://qi-hw.com/p/openwrt-packages/aa543e6 |
| 05:03.50 | qi-bot | [commit] kyak: libnsgif: initial port (master) http://qi-hw.com/p/openwrt-packages/fae1844 |
| 05:03.52 | qi-bot | [commit] kyak: netsurf: update to 2.9 (master) http://qi-hw.com/p/openwrt-packages/a328712 |
| 05:03.54 | qi-bot | [commit] kyak: Merge branch 'master' of projects.qi-hardware.com:openwrt-packages (master) http://qi-hw.com/p/openwrt-packages/b5ffbdf |
| 05:06.13 | kyak | hm.. i forgot how to avoid the "Merge branch 'master'" commits... |
| 05:06.29 | kyak | i though git pull before git push was enough |
| 05:06.54 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 05:11.08 | pabs3 | git pull is essentially git fetch + git merge |
| 05:11.28 | pabs3 | I think you want git fetch + git rebase, or git pull --rebase |
| 05:16.15 | wolfspraul | kyak: do you know the state of vnc on the Ben? |
| 05:16.35 | wolfspraul | sometimes I keep wondering about it - I vaguely remember once there was a problem because some client required an X backend |
| 05:17.06 | wolfspraul | but I've used clients on framebuf before, so not sure. In the packages repo, I find vnc-reflector, vncrepeater and libvncserver |
| 05:17.54 | wolfspraul | any known vnc clients for Ben? |
| 05:20.32 | kyak | pabs3: ah, indeed! |
| 05:21.02 | kyak | wolfspraul: i have no idea.. :) |
| 05:21.10 | kyak | never tried that |
| 05:21.16 | wolfspraul | ok sure, I shall investigate |
| 05:22.32 | kyak | i only see vnc proxy and vnc repeater packages in openwrt |
| 05:22.42 | kyak | and some vnc server library |
| 05:22.47 | wolfspraul | yes |
| 05:23.02 | *** part/#qi-hardware blogic (~blogic@openwrt/developer/blogic) |
| 05:23.28 | kyak | oh |
| 05:23.33 | kyak | "i need new eye" |
| 05:23.42 | kyak | you said that :) |
| 05:24.43 | kyak | if we find sdl vnc client, we might have a chance |
| 05:25.41 | kyak | but then, it's just 320x240.. what is the use case you are thinking about? |
| 05:27.28 | kyak | http://www.ferzkopp.net/Software/SDL_vnc/ - this is something really basic |
| 05:27.41 | kyak | and old, too |
| 05:30.04 | wolfspraul | use case anticipates future higher resolutions :-) |
| 05:30.29 | wolfspraul | I've used a vnc client on framebuf before, but forgot which one it was. there are so many clients... |
| 05:30.40 | kyak | http://svn.icculus.org/palantir/trunk/ - this is another sdl vnc client |
| 05:31.00 | wolfspraul | ah, directvnc |
| 05:31.05 | wolfspraul | that was the one I used |
| 05:31.25 | kyak | ah looking good |
| 05:31.29 | wolfspraul | yes, sdl might also be an option. I'm looking for the shortest path to something that already exists... but no worries, I'll look around |
| 05:31.33 | kyak | not very old also |
| 05:32.04 | kyak | directfb is probably better than sdl if it works |
| 05:38.18 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 05:48.36 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 06:02.15 | wolfspraul | DocScrutinizer: hi good morning :-) |
| 06:03.03 | wolfspraul | you mentioned boundary scan tests the other day, in passing with design rule checks |
| 06:03.40 | wolfspraul | I think for design rules, we are already on a good path, at least knowledge-wise, the rest is a matter of implementing and documenting |
| 06:03.54 | *** join/#qi-hardware pabs3 (~pabs@d122-109-116-184.per801.wa.optusnet.com.au) |
| 06:03.58 | wolfspraul | but how about jtag boundary scans? can you describe in a bit more detail what kind of testing you had in mind? |
| 07:13.19 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 07:16.21 | qi-bot | [commit] Adam Wang: correcting NC pins to Unspecified electrical type. (master) http://qi-hw.com/p/kicad-libs/b864df8 |
| 07:16.22 | qi-bot | [commit] Adam Wang: correct Vcc to Power input electrical type (master) http://qi-hw.com/p/kicad-libs/55ba6c9 |
| 07:16.23 | qi-bot | [commit] Adam Wang: added DIN_5_2S with two pin shields (master) http://qi-hw.com/p/kicad-libs/e43dcbe |
| 07:17.42 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 08:01.19 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 08:51.34 | DocScrutinizer | wolfspraul: see http://en.wikipedia.org/wiki/Boundary_scan |
| 08:53.36 | DocScrutinizer | JTAG originally was meant for boundary_scan, it's just over time that people only know about >>When used during manufacturing, such systems also support non-test but affiliated applications such as in-system programming of various types of flash memory: NOR, NAND, and serial (I2C or SPI). |
| 08:54.27 | DocScrutinizer | and |
| 08:54.30 | DocScrutinizer | >>The boundary scan architecture also provides functionality which helps developers and engineers during development stages of an embedded system. A JTAG Test Access Port (TAP) can be turned into a low-speed logic analyzer. |
| 08:55.08 | DocScrutinizer | ~wiki jtag |
| 08:55.30 | DocScrutinizer | "Joint Test" is the keyword |
| 09:00.05 | DocScrutinizer | wolfspraul: to put it as simple as it basically is: JTAG boundary scan is a huge "cable tester" |
| 09:01.00 | DocScrutinizer | with your JTAG-BS aware chip at one end of cable, and either another such chip or some test equipment outside your PCB at the other end of "cable" |
| 09:02.15 | DocScrutinizer | then you check each "wire" (aka trace / solder point) for connection and for isolation to neighbours |
| 09:04.17 | DocScrutinizer | this is obviously simple to implement for GPIO, without JTAG-BS. Not though for other buses and lines, like addr bus from SoC to RAM or whatever. Also not for lines that have one dedicated other function in normal operation, like on/off-switch or whatever |
| 09:07.24 | DocScrutinizer | basically you can "remove" the function core of a bs-aware chip from your circuit, and "replace" it with a logic tester, so you can read in _and_ _set_ logic level of _each_ pin of the chip - except VDD, GND, 4 JTAG pins |
| 09:09.09 | DocScrutinizer | JTAG quite usually gets daisychained, so all your chips form one long chain of JTAG blocks that's controlled over just one JTAG connector to your PCB |
| 09:10.04 | DocScrutinizer | ;s/over/via/ |
| 09:32.48 | DocScrutinizer | >>The ability to perform such testing on finished boards is an essential part of Design For Test in today's products, increasing the number of faults that can be found before products ship to customers.<< |
| 09:34.26 | DocScrutinizer | and especially for you ;-) >>... JTAG scan chain enables a **low overhead**, embedded solution to testing an IC for certain static faults (shorts, opens, and logic errors).<< |
| 09:51.02 | DocScrutinizer | wolfspraul: btw DSC like I define it, is an automatic check of properties of one pin against the properties of other pins on same trace. Like "no 2 outputs on same trace", "high level defined voltage (range) same (resp matching) for output and all inputs" etc |
| 09:51.10 | DocScrutinizer | DRC* |
| 09:51.54 | wolfspraul | understood - have to do some background reading but I'll get to that. thanks a lot! |
| 09:52.27 | DocScrutinizer | of course you regularly need to augment the defualt checks, if you use nifty design which might allow 2 tristate outputs on same trace, when driven correctly |
| 09:54.54 | DocScrutinizer | basically for each trace/net you have a DRC that consists of property definitions of all the pins, plus a transformation algo that's empty for plain wire nets but something rather complex for e.g. bus with 50R termination |
| 09:56.11 | DocScrutinizer | then some spice-alike equation solver runs each net to check if the equation results in "good" or in "mismatch" |
| 09:57.27 | DocScrutinizer | open pins are a very interesting case for that |
| 10:00.52 | DocScrutinizer | (nifty design with tristate) usually you get a 3rd class of equation solver results: warnings |
| 10:03.13 | DocScrutinizer | "WARNING! two outputs on same trace. Mismatch for (p238:out:1 && p317:out:0), (p238:out:0 && p317:out:1) |
| 10:05.00 | DocScrutinizer | for GPIO exactly same warning |
| 10:05.49 | DocScrutinizer | for a case where one of both not tristate but totempole output, this becomes "ERROR!" |
| 10:06.34 | DocScrutinizer | same "ERROR!" if for 2 GPIO the power-on defualt of one is incompatible with power-on default of the other |
| 10:08.16 | DocScrutinizer | all those infos (tristate output, H-voltage range, L-voltage range, power-on default...) need to get stored with the pins of component in CAD |
| 10:10.29 | DocScrutinizer | the equation solver engine runs one solution for each of the pin's possible states: H, L, high-Z, input, pullup, pulldown... |
| 10:12.31 | DocScrutinizer | like with lint you'll want to "comment out" some warnings, by e.g. defining pull-up and output as illegal for a GPIO |
| 10:13.50 | DocScrutinizer | all those "lint comments" will get shipped to sw-engineers to let them know what they must avoid to ever do |
| 10:14.19 | DocScrutinizer | a good hw design has an empty such list |
| 10:17.39 | DocScrutinizer | for e.g. the simplest case of 2 GPIO connected you do this by connecting them via a 50R, so there's no exceeding load to either of both when one is output:1 and other is output:0 |
| 10:19.25 | DocScrutinizer | unless of course your properties of both pins would allow such pathological case without any violation of ABS MAX ratings for fan out |
| 10:20.29 | DocScrutinizer | (means: one of the GPIO has some "internal 50R" so it's short circuit tolerant and also won't overload the other GPIO) |
| 10:23.40 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 10:23.45 | *** join/#qi-hardware antoniodariuh_ (~antonioda@nat-sta-slph1.tvu.ac.uk) |
| 10:25.41 | *** join/#qi-hardware cladamw_ (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 10:29.01 | qi-bot | [commit] Xiangfu: nanonote-files: cleanup etc/ files (master) http://qi-hw.com/p/openwrt-packages/78095b1 |
| 10:36.12 | qi-bot | [commit] Xiangfu: xburst: nanonote: move Ben special files to it's package (master) http://qi-hw.com/p/openwrt-xburst/c6e40d3 |
| 10:37.34 | DocScrutinizer | wolfspraul: probably quite a different approach to DRC than the trace-geometrics check we usually see in layout CAD, hm? :-) |
| 10:39.24 | qi-bot | [commit] Xiangfu: nanonote-files: config.full_system: remove non-compile packages (master) http://qi-hw.com/p/openwrt-packages/4ff5437 |
| 10:42.14 | qi-bot | [commit] Adam Wang: added 6N138, 8-Pin SMD Single-Channel Low Input Current High Gain Split Darlington Output Optocoupler (master) http://qi-hw.com/p/kicad-libs/de234eb |
| 10:48.00 | kyak | xiangfu: some packages you removed are actually fixed, like centerim, dgclock.. |
| 10:48.23 | kyak | nightsky, netsurf, what else.. |
| 10:51.00 | kyak | it probably makes sense not to remove broken packages, but rather make them =m or mark as @BROKEN in Makefile, so people woudl know |
| 10:55.20 | xiangfu | kyak, oh. |
| 10:55.20 | qi-bot | [commit] Xiangfu: Revert "nanonote-files: config.full_system: remove non-compile packages" (master) http://qi-hw.com/p/openwrt-packages/e3b5136 |
| 10:55.21 | qi-bot | [commit] Xiangfu: nanonote-files: remove nlove, jamvm, pygame. add libnl-tiny (master) http://qi-hw.com/p/openwrt-packages/83f3429 |
| 10:56.40 | kyak | i'd really prefer marking them @BROKEN, so that we know what to fix |
| 10:56.44 | xiangfu | kyak, mark as @BROKEN. yes agree. |
| 10:58.10 | xiangfu | kyak, but I think just remove from config.full_system and mark as @BROKEN |
| 10:58.28 | xiangfu | =m is like comment :-) |
| 10:59.51 | kyak | yeah, if you mark it as @BROKEN, =m doesn't make sense |
| 11:00.13 | xiangfu | kyak, thanks. marking @BROKEN now.. |
| 11:01.46 | xiangfu | kyak, I saw you update 'netsurf' a lot, cool |
| 11:02.38 | qi-bot | [commit] Xiangfu: mark nlove, offrss, pygame as @BROKEN (master) http://qi-hw.com/p/openwrt-packages/5a2adbf |
| 11:02.38 | kyak | yeah, but if you read the comment to netsurf commit, it's not quite so cool |
| 11:02.54 | xiangfu | kyak, I am try to add new 'gmen2x' icons to nanonote-files. since gmenu2x have broken. :( |
| 11:03.07 | DocScrutinizer | wolfspraul: with DRC like I define it, odd quirks like the "LED eating massive current" in GTA02A5 never had crept in |
| 11:03.40 | xiangfu | kyak, yes I saw the comment and 'gmenu2x' revert. :-) |
| 11:04.24 | kyak | xiangfu: actually, it makes more sense to keep icons in nanonote-files repo rather than gmenu2x repo |
| 11:04.24 | DocScrutinizer | catching the 1uF (instead 100uF) in hs-audio would have needed a rather complex DRC rules set, but in principle even that would have been detectable |
| 11:04.45 | kyak | gmenu2x repo is for gmenu2x development, not for new icons commits :) |
| 11:05.27 | xiangfu | kyak, yes. |
| 11:05.33 | xiangfu | kyak, let's do it. :-) |
| 11:05.37 | kyak | yep! |
| 11:05.47 | DocScrutinizer | ...depending on powers of equation solver |
| 11:05.50 | xiangfu | I am moving the icons now.. |
| 11:06.29 | kyak | and if things go well with David's fancy new shell, who knows, maybe gmenu2x may as well have a rest |
| 11:08.56 | qi-bot | [commit] Xiangfu: move nanonote gmen2x icons from gmen2x.git to here (master) http://qi-hw.com/p/openwrt-packages/cb90452 |
| 11:09.08 | qi-bot | [commit] Xiangfu: move all Ben Nanonote icons to it's nanonote-files packages (master) http://qi-hw.com/p/gmenu2x/a881e78 |
| 11:12.01 | xiangfu | kyak, let me stop the current build see if we can get a clean build for next release. (include all recently commits) |
| 11:12.46 | kyak | m |
| 11:12.56 | kyak | you need to mark gcc-mips as broken |
| 11:13.11 | kyak | i wasn't able to get to it yet.. |
| 11:13.25 | kyak | then probably it would all build |
| 11:14.40 | qi-bot | [commit] Xiangfu: gcc-mips mark as broken (master) http://qi-hw.com/p/openwrt-packages/7eb4f78 |
| 11:15.51 | xiangfu | kyak, ok. the current build haved stop. let's see how next build going... |
| 11:16.12 | kyak | xiangfu: great! |
| 11:16.25 | xiangfu | the build will start in next 3 hours. those 3 hours buildhost is busy on milkymist one compile . |
| 11:16.49 | kyak | wolfspraul: this is directvnc running on Ben trying to connect to vnc server on my laptop running xterm :) http://downloads.qi-hardware.com/people/kyak/tmp/directvnc.png |
| 11:17.07 | kyak | it looks pretty bad.. has something to do with directfb |
| 11:17.23 | kyak | bad it somewhat works.. i typed uname -a :) |
| 11:18.47 | kyak | xiangfu: btw, nmap and tcpdump fail to build for me.. didn't have a closer look yet |
| 11:18.59 | kyak | we have tcpdump in full config, might cause problems.. |
| 11:19.56 | xiangfu | tcpdump compile fine under build host. |
| 11:20.04 | xiangfu | kyak, http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.minimal-20120402-0952/packages/tcpdump_4.2.1-1_xburst.ipk |
| 11:20.05 | kyak | oh, ok |
| 11:20.21 | xiangfu | I use a config.minimal build to check if package compile find. |
| 11:21.18 | qi-bot | [commit] Xiangfu: nanonote-files: don't use manually edit config file (master) http://qi-hw.com/p/openwrt-packages/2b11c51 |
| 11:21.48 | xiangfu | kyak, BTW: the make kernel_menuconfig, in different system give different behavior. |
| 11:22.11 | xiangfu | kyak, I think you commit is works better under buildhost. which is good. |
| 11:22.21 | xiangfu | s/you/your |
| 11:22.21 | qi-bot | xiangfu meant: "kyak, I think your commit is works better under buildhost. which is good." |
| 11:22.34 | kyak | xiangfu: yeah, i remember that kernel_menuconfig was buggy, but i tried this time, and it worked just fine |
| 11:23.02 | *** join/#qi-hardware jekhor (~jek@mx2.promwad.com) |
| 11:23.25 | kyak | btw, what;s the difference between config.autogen and config? |
| 11:24.41 | xiangfu | kyak, I manually edit some config in latest release. since there are too many package not compile in latest release. |
| 11:25.07 | xiangfu | kyak, now back to normal. |
| 11:25.11 | kyak | ah, ok |
| 11:26.05 | xiangfu | kyak, have to go. see you later. |
| 11:26.14 | kyak | see you! |
| 11:28.11 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 11:30.06 | *** join/#qi-hardware jivs_ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 11:43.34 | *** join/#qi-hardware GNUtoo (~gnutoo@host149-73-dynamic.56-82-r.retail.telecomitalia.it) |
| 11:44.35 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 11:45.02 | *** join/#qi-hardware zoltanh7211 (~zoltanh72@54001FB6.dsl.pool.telekom.hu) |
| 11:45.16 | zoltanh7211 | Hi guys |
| 11:45.45 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 11:56.04 | wpwrak | DocScrutinizer: (JTAG) interesting ... i always considered "Joint" an attribute of "Group", not of "Test". similar to "junta". in the sense of multi-vendor. |
| 11:56.23 | zoltanh7211 | rejon ping |
| 11:57.15 | DocScrutinizer | wpwrak: unclear |
| 11:57.24 | DocScrutinizer | for me it's "joint test" |
| 11:57.51 | DocScrutinizer | as that's basically what JTAG-BS is all about |
| 11:58.18 | DocScrutinizer | both INT (for bonding) and EXT (for solder joints) |
| 11:58.27 | DocScrutinizer | nah, not exactly< bonding |
| 11:58.33 | DocScrutinizer | bonding also is EXT |
| 11:58.39 | DocScrutinizer | obviously :-) |
| 11:58.56 | zoltanh7211 | wolfspraul ping |
| 11:59.24 | wpwrak | DocScrutinizer: (DRC) we have a primitive test of that kind in eeschema (called ERC, electrical ...). you set pin types and it checks for compatibility. here's a view of schematics symbols with pin types http://people.openmoko.org/werner/gta02-core/gta02-core-expanded-all.pdf |
| 11:59.48 | DocScrutinizer | wpwrak: nice |
| 11:59.58 | wpwrak | DocScrutinizer: or the (work in progress) qi-hw variant: http://downloads.qi-hardware.com/people/werner/tmp/out.pdf |
| 12:04.24 | wpwrak | kyak: (gcc-mips broken) so that's "game over" ? :) |
| 12:05.23 | DocScrutinizer | wpwrak: if your pin types are sufficiently detailed, in a sense that BiDi(S4C4554) := GPIO_type3(1.8V,pu+pd,fan-out=8) |
| 12:05.35 | kyak | wpwrak: no, not at all.. just everything has its time.. too many packages broke since last release |
| 12:05.44 | wpwrak | kyak: (for what it's worth, i ran yesterday into the problem of the owrt build process trying to download unavailable gcc-4.6-linaro) |
| 12:05.49 | DocScrutinizer | then this is even better than declaring each and every parameter for each and every pin again |
| 12:06.03 | wpwrak | kyak: ah, so it builds but some exotic features don't work ? |
| 12:06.31 | wpwrak | kyak: (gcc download) that was following http://en.qi-hardware.com/wiki/Building_Software_Image |
| 12:06.39 | kyak | wpwrak: no, it doesn't build :) not with the updated toolchain of openwrt |
| 12:06.53 | DocScrutinizer | a generic BiDi for all levels of VDD_IO of course doesn't help that much |
| 12:07.09 | wpwrak | DocScrutinizer: yes, i said it's primitive ;-) |
| 12:07.11 | kyak | new gcc version, new uClibc version, gcc-mips is broken :) |
| 12:07.44 | DocScrutinizer | wpwrak: maybe primitive but we're on same page regarding principles |
| 12:07.48 | kyak | wpwrak: i regularly remove my dl/ dir.. didn't have the problem.. probably the mirror was down.. is it still the case? |
| 12:08.20 | kyak | wpwrak: are you followign the "Building OpenWrt based on release files" or "Building OpenWrt on last git commmit" steps? |
| 12:08.33 | wpwrak | kyak: one mirror was down, the others didn't have the directory. that's where i declared defeat :) |
| 12:09.26 | wpwrak | kyak: based on release files. playing it safe :) and i used the one that explicitly gives a commit (43a86619c3cb9aceaace51097bc35d59b7b8a4fc) |
| 12:10.24 | DocScrutinizer | roh: ping |
| 12:10.25 | wpwrak | kyak: imho, the approach of downloading things from all around the world is too fragile. it would be better to have a local (qi-hw) mirror that doesn't automatically propagate deletions |
| 12:10.45 | DocScrutinizer | roh: what are the plans regarding svn.openmoko.org now? |
| 12:11.12 | DocScrutinizer | roh: seems quite a number of people still need it |
| 12:11.37 | kyak | wpwrak: there is such thing.. once downloaded on buildhost, the tarball should be in http://downloads.qi-hardware.com/software/mirror-openwrt-sources/ |
| 12:12.01 | kyak | and the build system will try to pull it from there as a last resort |
| 12:12.26 | qi-bot | [commit] Adam Wang: added 1). BZX84 Voltage Regulator 2). SN75HVD12D RS-485 TRANSCEIVERS 3). JS28F256J3F105 FLASH (master) http://qi-hw.com/p/kicad-libs/a54fc4a |
| 12:12.41 | kyak | now, i wonder why linaro-4.6... if you base on a last release, it should be linaro-4.5 |
| 12:13.10 | kyak | wpwrak: how about you do it based on a last commit? :) |
| 12:14.20 | wpwrak | kyak: (mirror) sounds good. but perhaps it should be used first ? after all, that's what has been tested. |
| 12:14.28 | wpwrak | kyak: (linaro) ftp://ftp.uu.net/archive/systems/gnu/gcc/gcc-4.6-linaro/gcc-4.6-linaro.tar.bz2 |
| 12:15.38 | wpwrak | kyak: (lates commit) i think i'll give it a try again when the dust has settled :) for now, i'm using an old toolchain i found in a backup ... and build static binaries :) |
| 12:15.47 | kyak | wpwrak: i think the intention is to try to download from the "official" location, then fallback to the cached mirror |
| 12:16.20 | kyak | btw, the commit number in wiki is just an example |
| 12:16.31 | wpwrak | kyak: (official) yes, but does that provide any practical benefit ? |
| 12:16.39 | kyak | you should use the real release_ branch or find the correct hash |
| 12:18.05 | wpwrak | kyak: (example) hmm. why are there so many manual steps anyway ? wouldn't a "git pull ....; make release" be possible as well ? |
| 12:18.45 | wpwrak | kyak: or maybe "make toolchain". which should be one of the main reasons for wanting to go through all this anyway :) |
| 12:19.28 | kyak | the page is about building images, i guess |
| 12:19.41 | kyak | if you want the toolchain - just download it |
| 12:20.07 | kyak | what do you mean by "manual steps"? |
| 12:20.08 | qi-bot | [commit] Adam Wang: added 1). FSMRA2JH switch 2). IR 3). Oscillator 4). XLR 3 pole female/male receptacle (master) http://qi-hw.com/p/kicad-libs/e3ebf0a |
| 12:21.53 | wpwrak | (official source) what i usually see is: 1) upstreams sometimes reorganize, changing paths. 2) upstreams sometimes delete old things (which we may still reference). 3) upstreams sometimes find horrible problems (package corruption or malware). they tend to resolve this in two ways: 3a) upload a fixed version. 3b) more common, delete the bad version and make a new version. 4.13 -> 4.13a or such. 4) upstreams sometimes migrate to a diff |
| 12:21.53 | wpwrak | erent site. 5) upstreams sometimes simply die. |
| 12:22.29 | wpwrak | and 6) upstream is temporarily down |
| 12:22.47 | kyak | for everything you have mentioned, there is a fallback mirror |
| 12:23.19 | kyak | and also md5sum |
| 12:23.21 | wpwrak | in cases 1, 2, 3b, 4, and 5, the local mirror wins. in case 6, it usually wins too, because we need it to fetch other items as well, so it'll have to be up anyway |
| 12:23.49 | wpwrak | only in case 3a there would be an advantage of preferring upstream over mirror |
| 12:24.59 | kyak | wpwrak: could you better tell me, how to make JZ4740 FB work in 16 bpp mode? :) |
| 12:25.11 | kyak | to avoid this horrible mess: http://downloads.qi-hardware.com/people/kyak/tmp/directvnc.png |
| 12:25.28 | wpwrak | (fallback) yes, i don't know why it didn't work. the build first failed silently. then i ran it again with V=99 but i stopped it after trying "upstream" mirrors for something like half an hour. so it never got to the local mirror (i didn't expect one at that point anyway) |
| 12:25.34 | kyak | directvnc doesn't support 32 bpp, JZ4740 FB doesn't support 16 bpp |
| 12:25.57 | wpwrak | looks pretty :) |
| 12:26.46 | wpwrak | ah no, i don't know offhand how to change the color depth. trial and error are your friends ;-) |
| 12:27.43 | kyak | trial and error and, probably, larsc :) |
| 12:27.45 | wpwrak | (mirror) or perhaps there could be some option to change the order ? ideally, it would default to picking the local mirror first :) |
| 12:27.46 | roh | kyak: there are many colorspaces in 16 and 32bit as well |
| 12:28.03 | kyak | larsc: do you have an idea how to make JZ4740 FB work in 16 bit mode? |
| 12:28.35 | kyak | wpwrak: of course there is an "option" :) in scripts/download.pl |
| 12:28.51 | kyak | roh: what do you mean? |
| 12:29.19 | roh | byte-order, color depth |
| 12:29.37 | roh | 32bit can be 24bit padded, with alpha... different orders |
| 12:29.56 | roh | 16bit can be 565 or sth. else, different orders... |
| 12:30.36 | roh | there are many ways to use 16 or 32bit for encoding colors |
| 12:30.38 | wpwrak | kyak: nice ! thanks ! |
| 12:32.17 | roh | hmmmm |
| 12:32.24 | roh | http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/master/target errors out for me |
| 12:32.45 | roh | error 500 |
| 12:32.53 | kyak | roh: i'm sorry, i don't quiet get you.. is there any way to make it work in JZ4740 FB driver? |
| 12:33.42 | kyak | yeah, 500 for me, too.. strange |
| 12:33.47 | roh | dunno. just noted that there are not only a number of bits to know, but also which order and format the colors are in there |
| 12:37.58 | wolfspraul | bah the indefero server :-) |
| 12:38.28 | wolfspraul | too bad zoltan left already... |
| 12:48.57 | larsc | kyak: on the nanonote? |
| 12:53.27 | kyak | larsc: yep.. |
| 12:55.04 | kyak | larsc: i'm trying to launch directvnc, which doesn't support 32 bpp (so i laucnh it in 16bpp). So i see something like this http://downloads.qi-hardware.com/people/kyak/tmp/directvnc-xeyes.png (the image is compressed by the half of screen) |
| 13:12.25 | kyak | or probably it is directvnc that needs to be fixed.. since i see exactly the same picture on my laptop - just a half of the screen |
| 13:14.13 | *** join/#qi-hardware newcup (newcup@peruna.fi) |
| 13:25.41 | larsc | kyak: yes that sounds like a better option. |
| 13:26.49 | larsc | the framebuffer needs it in 32bit |
| 13:30.17 | wolfspraul | kyak: I have no idea how this patch ends up in my people folder, but if you want to see a really crude version for 32bpp supports in directvnc, have a look at http://downloads.qi-hardware.com/people/wolfgang/tmp/directvnc-0_7_5.patch |
| 13:36.53 | kyak | larsc: i see |
| 13:37.02 | kyak | wolfspraul: heh, nice, giving it a try |
| 13:37.47 | wolfspraul | it's just a few lines, and did the trick on a notebook I setup a little while back |
| 13:44.27 | kyak | hm |
| 13:44.33 | kyak | something has definitely changed |
| 13:44.41 | kyak | it is full screen now, but still mangled |
| 14:14.32 | *** join/#qi-hardware wpwrak (~werner@234-171-231-201.fibertel.com.ar) |
| 15:05.08 | *** join/#qi-hardware zoltanh7211 (~zoltanh72@54001F8C.dsl.pool.telekom.hu) |
| 15:05.15 | zoltanh7211 | re |
| 15:08.05 | zoltanh7211 | wolfspraul ping |
| 15:18.11 | *** join/#qi-hardware rejon_ (~rejon@jp.fabricatorz.com) |
| 15:22.19 | zoltanh7211 | rejon ping |
| 15:24.05 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 15:48.41 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 15:55.23 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 15:55.26 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 15:57.17 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 16:26.44 | kyak | mth: there is another regression in gmenu2x (also somewhere around these commits).. the "workdir" parameter in icon file is ignored |
| 16:27.24 | kyak | ah, i read "Removed ability to configure custom working directory." |
| 16:27.57 | kyak | well yeah.. it turns out to be useful |
| 16:28.44 | kyak | like when we launch ash from gmenu2x, we want it to change to home dir |
| 16:28.52 | kyak | it's ugly when it starts in /usr/bin |
| 16:40.05 | wpwrak | kyak: use a wrapper script ? |
| 16:42.23 | kyak | wpwrak: frankly speaking, i don't want to.. the icon file itself is already a "wrapper" |
| 16:45.45 | wpwrak | i woud seem to be |
| 16:45.51 | wpwrak | let's try this again |
| 16:47.48 | wpwrak | it would seem to be the unix way - don't create omnipotent applications but rather solve the problem with modular pieces. a little #!/bin/ash cd $HOME exec /bin/ash "$@" doesn't seem overly troublesome :) |
| 16:48.01 | wpwrak | but of course, i can't make you like it :) |
| 16:49.32 | wpwrak | oh, and why i tried the image build to get a toolchain: that's where google leads you when looking for "nanonote" and "toolchain". not sure if there's a more streamlined process anywhere. |
| 16:54.41 | mth | kyak: is it just ash that has this problem or more programs? |
| 16:55.30 | mth | currently gmenu2x is rather difficult to maintain and use, mostly because it has dozens of features |
| 16:56.19 | mth | well, the way the code is structured is the actual cause for the maintenance problems, but the more features there are, the harder it is to restructure |
| 17:19.23 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.243) |
| 17:42.50 | *** join/#qi-hardware zrafa (~rafa@190.14.174.29) |
| 17:47.50 | kyak | mth, wpwrak: i understood and agree with your points.. indeed, the cleaner gmenu2x's code, the better for us. |
| 17:49.15 | kyak | wpwrak: if you just need the toolchain, i can get it here: http://downloads.qi-hardware.com/software/images/NanoNote/Ben/2011-11-13/ |
| 17:49.28 | kyak | s/i/you |
| 17:49.28 | qi-bot | kyak meant: "wpwrak: youf you just need the toolchayoun, you can get yout here: http://downloads.qyou-hardware.com/software/youmages/NanoNote/Ben/2011-11-13/" |
| 17:49.37 | kyak | ha! |
| 17:50.50 | kyak | btw, you are also checking out a pretty old release (2011-05-28).. maybe that's why you have troubles downloading the sources |
| 17:52.02 | kyak | test |
| 17:52.07 | kyak | s/./ff |
| 17:52.08 | qi-bot | kyak meant: "ffffffff" |
| 17:52.34 | kyak | s/s/z |
| 17:55.32 | kyak | deadbeaf |
| 17:55.42 | kyak | s/(\S{4})(\S{4})/\2\1 |
| 17:55.42 | qi-bot | kyak meant: "beafdead" |
| 18:03.17 | whitequark | lol |
| 18:14.11 | whitequark | http://www.phoronix.com/scan.php?page=news_item&px=MTA4Mjg |
| 18:14.14 | whitequark | iiinteresting |
| 18:15.03 | whitequark | DocScrutinizer: what do you think about the article? |
| 18:25.19 | *** join/#qi-hardware wej (~j@95.211.92.234) |
| 18:25.42 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.67) |
| 18:44.36 | *** join/#qi-hardware jekhor (~jek@46.216.72.74) |
| 18:50.19 | DocScrutinizer | indeed lol, regarding it does full pearl regex but implicitly assumes /g |
| 18:55.07 | DocScrutinizer | umm, this article... coreboot, ChromeOS... errr :-S |
| 18:57.20 | whitequark | what? |
| 19:01.48 | DocScrutinizer | hm? |
| 19:03.21 | *** join/#qi-hardware uwe_ (~uwe_@dslb-088-066-186-052.pools.arcor-ip.net) |
| 19:19.45 | whitequark | what's with it? |
| 19:19.52 | whitequark | I thought coreboot was a good project |
| 19:45.10 | DocScrutinizer | well, probably it is |
| 19:45.44 | DocScrutinizer | though I'm not sure if it's just another BIOS, or that nonsensical bios based mp3 player |
| 19:45.59 | whitequark | err, a FOSS BIOS |
| 19:46.09 | whitequark | no idea what mp3 player you're talking about |
| 19:56.58 | DocScrutinizer | there's a BIOS that does media and stuff without any OS booting |
| 19:57.21 | DocScrutinizer | sure a FOSS BIOS is a nice thing |
| 20:01.01 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 20:10.42 | *** join/#qi-hardware capiscuas (~capiscuas@ppp-58-8-213-19.revip2.asianet.co.th) |
| 20:44.35 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-146-20.w109-222.abo.wanadoo.fr) |
| 20:53.43 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 21:24.47 | GNUtoo | it's a very nice thing, I did the port on my desktop mainboard |
| 21:33.31 | wpwrak | kyak: (toolchain) thanks ! for now i'm good. i'll probably give it another try in a week or so. |
| 21:52.23 | *** part/#qi-hardware zoltanh7211 (~zoltanh72@54001F8C.dsl.pool.telekom.hu) |
| 23:13.16 | *** join/#qi-hardware dvdk (~dvdkhlng@g225038148.adsl.alicedsl.de) |
| 23:18.52 | dvdk | hmm, mplayer segfaults in uclibc |
| 23:35.19 | *** join/#qi-hardware wpwrak (~werner@234-171-231-201.fibertel.com.ar) |
| 23:45.36 | dvdk | hmm, have to disable freetype support in mplayer, to make it run with 'fbdev' output. accelerated output still crashing, though |
| 23:48.43 | dvdk | correction, mplayer crashes somewhere in /lib/ld-uClibc-0.9.33.so, wtf? |
| 23:56.59 | wolfspraul | how good is our debugging on the Ben setup actually? |
| 23:57.21 | dvdk | well, not at all? :) |
| 23:57.25 | wolfspraul | should we auto-build images or packages with debug info turned on? |
| 23:57.47 | dvdk | wolfspraul: debug info is not kept on nanonote, but on build system. |
| 23:57.54 | wolfspraul | and how would one be able to capture that then in case of a crash? |
| 23:58.03 | wolfspraul | yeah, I know it's tedious, so wondering |
| 23:58.10 | wolfspraul | every time there is a crash it's like the world stops :-) |
| 23:58.40 | wolfspraul | normally you would just want to know the source code line and maybe a few local variables and that would allow you to go one step further in 95% of cases |
| 23:58.53 | dvdk | well, currently i'm debugging with gdb but without debug info. assembler dumps plus checking memory mapping |
| 23:59.48 | dvdk | currently the easiest way is to recompile a buggy package with debug info, then test that. |
