2012-04-04 00:02 Jay7 has joined #qi-hardware 2012-04-04 00:18 cladamw has joined #qi-hardware 2012-04-04 01:06 DocScrutinizer: glamo docs are fully public now, Sean got permission to release them 2012-04-04 01:10 (well, unless there are some he didn't have or forgot about) 2012-04-04 01:17 yes it is 2012-04-04 01:17 mplayer 2012-04-04 01:17 segfautls.. 2012-04-04 01:17 or. 2012-04-04 01:17 in my image.. 2012-04-04 01:22 Okay, confirmed i'll be there http://softwarelibre.info 2012-04-04 01:23 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.. 2012-04-04 01:23 nice! 2012-04-04 01:25 yeah.. well, i would like to spare time for more activities but :) 2012-04-04 01:26 who is the audience? 2012-04-04 01:26 rejon has joined #qi-hardware 2012-04-04 01:27 students, mature people (who also pay tickets? btw..) 2012-04-04 01:27 i'm not very aware of FLOSS audience in the Ecuador so, all is new.. 2012-04-04 01:28 ah, i guess people from oter floss based enterprises as well.. 2012-04-04 01:43 * pabs3 wonders if kristianpaul will take some opencores stuff too 2012-04-04 01:44 i take milkymist cores too ;-) 2012-04-04 01:44 but i dont want get too tech at leas is necesary, remenber is floss event.. 2012-04-04 01:44 I meant http://opencores.org/ 2012-04-04 01:45 pabs3: have you developed for fpgas? which opencores cores have you found usable? 2012-04-04 01:45 no 2012-04-04 01:45 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 :-) 2012-04-04 01:46 indeed, i havent time to look at opencores, perhpas the ethernet and usb ones.. but ... nah to lazy to compare 2012-04-04 01:46 given that Linux supports OpenRISC now, I guess something from there is working 2012-04-04 01:46 it works indeed 2012-04-04 01:46 and openrisc SoC is a fact for that 2012-04-04 01:46 indeed 2012-04-04 01:47 have either of you tried it? 2012-04-04 01:47 hey wolfspraul 2012-04-04 01:47 * kristianpaul waiting stekern release its openrisc port to M1.. 2012-04-04 01:47 got my mail? 2012-04-04 01:48 kristianpaul: yep :-) 2012-04-04 01:48 that would be great 2012-04-04 01:48 pabs3: do you have a url for "linux supports openrisc"? 2012-04-04 01:48 who is using it? have they documented their work? 2012-04-04 01:48 * pabs3 goes looking 2012-04-04 01:49 of course I know these statements for months, years. but a lot seems to be just hearsay. 2012-04-04 01:49 wolfspraul: http://kernelnewbies.org/Linux_3.1#head-37c60fa1253db74ce7d224718a71f5836bd5be09 2012-04-04 01:49 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 :-) 2012-04-04 01:49 pabs3: let's find users and documentation 2012-04-04 01:50 that would help us and/or stekern 2012-04-04 01:50 if it's open and it works, anybody should be able to use it 2012-04-04 01:50 roh: yes, got it - thanks! 2012-04-04 01:50 wolfspraul: hope you can meet. nice guy (mitch) 2012-04-04 01:50 pabs3: fyi stekern is a guy at #milkymist that hack around openrisc and its SoC 2012-04-04 01:51 fact is this: 2012-04-04 01:51 milkymist soc runs today, and afaik nothing stops us from replacing the lm32 core with an openrisc core 2012-04-04 01:52 except for 'a little' work :-) 2012-04-04 01:52 little, ha ;) 2012-04-04 01:52 well.. 2012-04-04 01:52 but for some reason Sebastien says the lm32 core is superior, and there must be a reason for that 2012-04-04 01:52 wej has joined #qi-hardware 2012-04-04 01:53 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 2012-04-04 01:53 or: fire up your code editor :-) 2012-04-04 01:53 I also hear that opencores has a 'great' 'linux supported' usb controller 2012-04-04 01:53 lm32 has its advantages yes, plus still small and not bad documented i think 2012-04-04 01:54 I try to follow opencores with the best intention for years, read their newsletter, browse projects, etc. 2012-04-04 01:55 but somehow it doesn't translate into reality 2012-04-04 01:55 but let's see 2012-04-04 01:55 stekern is our hope 2012-04-04 01:55 and maybe pabs3 buys a m1 soon and starts opencores hacking 2012-04-04 01:56 it's one thing that a developer sayss "this works great", or 100 or 1000 users actually agree with him :-) 2012-04-04 01:56 that's an entirely different thing in my experience 2012-04-04 01:56 like night and day - *that* different 2012-04-04 01:57 pabs3: does this make sense? let's start to *use* opencores stuff! 2012-04-04 01:57 indeed 2012-04-04 01:57 not just point to it, that's no news for years 2012-04-04 01:57 when we use it, we find out what really works 2012-04-04 01:57 personally I don't have the time nor disposable income to start working on that though 2012-04-04 01:57 we find out the nasty little details that make all the difference 2012-04-04 01:58 sure sure 2012-04-04 01:58 I did not in any way want to dismiss your input 2012-04-04 01:58 maybe one day you find the time and excitement 2012-04-04 01:58 understood :) 2012-04-04 01:58 opencores is great 2012-04-04 01:58 we all love it 2012-04-04 01:58 milkymist uses conbus core from it ! 2012-04-04 01:58 but so far I think not 1 line of any opencores core is running on m1 2012-04-04 01:58 why? 2012-04-04 01:58 strange 2012-04-04 01:58 AH! 2012-04-04 01:58 there you go 2012-04-04 01:59 wich is the thing glue all soc comunication :) 2012-04-04 01:59 kristianpaul: do you have a url into the opencores site to the original conbus? 2012-04-04 01:59 sure 2012-04-04 01:59 I mean the one that m1 reuses/uses 2012-04-04 01:59 I want to build more of those connections, make people understand where things come from so they can find more... 2012-04-04 01:59 http://opencores.org/project,wb_conbus 2012-04-04 02:00 I repeatedly hear 'openrisc' and also 'usb controller' 2012-04-04 02:00 well, the version is not the same, but that one in milkmist re-use most of the code i remenber 2012-04-04 02:00 kristianpaul: how much was the code changed when being brought over to m1? 2012-04-04 02:00 20-30% i bet 2012-04-04 02:00 havent dont full comparison 2012-04-04 02:01 that's the one thing in cores land that still confuses me 2012-04-04 02:01 how can people work together, and benefit from each others work 2012-04-04 02:01 is the m1 'fork' (?) of conbus known to the original conbus devs? 2012-04-04 02:01 do they care? 2012-04-04 02:01 i think i wrote him.. 2012-04-04 02:01 but never got reply.. 2012-04-04 02:02 are cores mostly a one-time heoric effort without much reuse or long-term value? 2012-04-04 02:02 then i find answer my self trought milkymist version ;) 2012-04-04 02:02 nice that you tried to establish contact 2012-04-04 02:02 no reply, oh well :-) 2012-04-04 02:03 * pabs3 goes to idle on #opencores 2012-04-04 02:03 pabs3: also sebastien sent back to opencores some cores from milkymist, the memory controller and navre (usb soft core= 2012-04-04 02:03 pabs3: no no 2012-04-04 02:03 too alone :) 2012-04-04 02:03 really :) 2012-04-04 02:03 I think the typical 'open core' (not a pun on opencores) is buggy like hell 2012-04-04 02:03 there are too few devs 2012-04-04 02:03 no quality standards 2012-04-04 02:03 no standardized test environments 2012-04-04 02:04 no expectation of reuse even, which makes devs even more reluctant to invest their time in reusability 2012-04-04 02:05 too many subtle details in different fpgas, even fpga generations, asic 2012-04-04 02:05 timing optimizations that eventually lead to a magic binary bitstream that nobody will touch or dare to ask how on earth it was made 2012-04-04 02:06 buggy vendor toolchains working against any efforts for better long-term quality and reusability 2012-04-04 02:06 more? :-) 2012-04-04 02:06 kristianpaul: would you agree? 2012-04-04 02:06 you are out in the minefield for a while now... you probably know what I mean, or can tell me if I'm wrong 2012-04-04 02:07 testing in general is under-appreciated in open cores 2012-04-04 02:07 yeah i know.. :-| 2012-04-04 02:07 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... 2012-04-04 02:07 actually the problem is not infinite, not at all 2012-04-04 02:07 also i followed opencores for while, until found you guys :D 2012-04-04 02:08 but there are *a lot* of shaky foundations right now, quicksand 2012-04-04 02:08 cores with a SoC. well... 2012-04-04 02:08 from a quality perspective, I think opencores is just a random assortment of all sorts of code snippets 2012-04-04 02:08 I think that's fair to say, althouhg I also don't know how to do better 2012-04-04 02:08 lets wait stekern news hopefully will give us better info about all this 2012-04-04 02:09 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 2012-04-04 02:09 kristianpaul: definitely :-) 2012-04-04 02:09 but most likely stekern will run into lots of nasty details 2012-04-04 02:09 on the surface it looks easy, but then... 2012-04-04 02:09 will he work through all of them? why? 2012-04-04 02:10 maybe just a few quick hacks enough for a demo or to say 'it works', then move to greener lands? 2012-04-04 02:10 to benchmark, that 'boring' need to be done anyway no? 2012-04-04 02:10 it's a chicken-egg problem 2012-04-04 02:10 hehe it works hacks :) 2012-04-04 02:10 no culture of reuse 2012-04-04 02:10 no investment in resuability 2012-04-04 02:10 reusability 2012-04-04 02:11 fully agree, on that one 2012-04-04 02:11 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 2012-04-04 02:11 and invest in high-quality documentation and testing 2012-04-04 02:11 until hopefully one day the real reuse and feed back cycle starts 2012-04-04 02:11 that's how I see it 2012-04-04 02:11 hmm may be we need first list SoC currently using wishbone and wishbone-like cores, plus compare what from opencores too 2012-04-04 02:12 would be good to do that on wikipedia though 2012-04-04 02:12 I'm editing milkymist-related information in wikipedia sometimes, as I learn. but could do more. 2012-04-04 02:13 there was also a port of milkymist soc to altera 2012-04-04 02:13 very exciting stuff imho 2012-04-04 02:13 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" 2012-04-04 02:13 one code tree 2012-04-04 02:13 one set of documentation 2012-04-04 02:13 oh, i need to dollow the editing of that article more often 2012-04-04 02:14 would be cool, but lots of work and again: why do it? if nobody reuses anyway :-) 2012-04-04 02:14 s/dollow/follow 2012-04-04 02:14 kristianpaul meant: "oh, i need to follow the editing of that article more often" 2012-04-04 02:16 lemme see, at least the url 2012-04-04 02:16 trying to build bridges :-) 2012-04-04 02:16 painful to build a bridge when nobody cares to use it anyway 2012-04-04 02:17 you rather just use a boat to cross the river once, for yourself 2012-04-04 02:17 much easier, right? 2012-04-04 02:17 here 2012-04-04 02:17 https://github.com/progranism/Open-Source-System-on-Chip-Experiment 2012-04-04 02:17 which Altera chip was this, one sec? 2012-04-04 02:18 cyclone III i bet 2012-04-04 02:18 great, can't even find in the README :-) 2012-04-04 02:19 and (*zero* blame to william here), there is not much effort to merge activities, or at least document/learn from each other 2012-04-04 02:19 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. 2012-04-04 02:19 that is already pioneering work! 2012-04-04 02:19 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. 2012-04-04 02:20 I think I must have seen this 10 times now with bits and pieces from milkymist, over the last 2 years. 2012-04-04 02:20 painful :-) 2012-04-04 02:20 so much wasted knowledge 2012-04-04 02:20 kristianpaul: you think cyclone III? 2012-04-04 02:21 seems he mentioned DE2_115 2012-04-04 02:22 ah, thats cyclone II i remenber 2012-04-04 02:22 no no 2012-04-04 02:23 argh, anywyay 2012-04-04 02:23 what I find looks like Cyclone IV EP4CE115 2012-04-04 02:24 oh much better 2012-04-04 02:24 he also i wodering now if he run on to routing problems.. 2012-04-04 02:24 need to as 2012-04-04 02:24 k 2012-04-04 02:25 wow that chip alone costs about 400 USD 2012-04-04 02:25 we have such great value on m1! 2012-04-04 02:25 ;) 2012-04-04 02:25 super high performance at low chip cost, and full focus on the open cores 2012-04-04 02:26 then we have noone but ourselves to blame :-) 2012-04-04 02:26 and the devkit sells for 300 USD :-) 2012-04-04 02:26 the de2-115 one 2012-04-04 02:28 I need to register/login with opencores to even view the sources? 2012-04-04 02:28 those kinds of things make me wonder about the platform, better move the sources to github even 2012-04-04 02:45 kristianpaul has joined #qi-hardware 2012-04-04 03:57 heyllo has joined #qi-hardware 2012-04-04 03:57 wassup 2012-04-04 05:03 [commit] kyak: libcss: update to 0.1.2 (master) http://qi-hw.com/p/openwrt-packages/b53ab42 2012-04-04 05:03 [commit] kyak: libhubbub: update to 0.1.2 (master) http://qi-hw.com/p/openwrt-packages/18bd88f 2012-04-04 05:03 [commit] kyak: libnsfb: update to 0.0.2 (master) http://qi-hw.com/p/openwrt-packages/a347d74 2012-04-04 05:03 [commit] kyak: libparserutils: update to 0.1.1 (master) http://qi-hw.com/p/openwrt-packages/e0300a0 2012-04-04 05:03 [commit] kyak: libwapcaplet: update to 0.1.1 (master) http://qi-hw.com/p/openwrt-packages/e1e92f2 2012-04-04 05:03 [commit] kyak: libnsbmp: initial port (master) http://qi-hw.com/p/openwrt-packages/aa543e6 2012-04-04 05:03 [commit] kyak: libnsgif: initial port (master) http://qi-hw.com/p/openwrt-packages/fae1844 2012-04-04 05:03 [commit] kyak: netsurf: update to 2.9 (master) http://qi-hw.com/p/openwrt-packages/a328712 2012-04-04 05:03 [commit] kyak: Merge branch 'master' of projects.qi-hardware.com:openwrt-packages (master) http://qi-hw.com/p/openwrt-packages/b5ffbdf 2012-04-04 05:06 hm.. i forgot how to avoid the "Merge branch 'master'" commits... 2012-04-04 05:06 i though git pull before git push was enough 2012-04-04 05:06 cladamw has joined #qi-hardware 2012-04-04 05:11 git pull is essentially git fetch + git merge 2012-04-04 05:11 I think you want git fetch + git rebase, or git pull --rebase 2012-04-04 05:16 kyak: do you know the state of vnc on the Ben? 2012-04-04 05:16 sometimes I keep wondering about it - I vaguely remember once there was a problem because some client required an X backend 2012-04-04 05:17 but I've used clients on framebuf before, so not sure. In the packages repo, I find vnc-reflector, vncrepeater and libvncserver 2012-04-04 05:17 any known vnc clients for Ben? 2012-04-04 05:20 pabs3: ah, indeed! 2012-04-04 05:21 wolfspraul: i have no idea.. :) 2012-04-04 05:21 never tried that 2012-04-04 05:21 ok sure, I shall investigate 2012-04-04 05:22 i only see vnc proxy and vnc repeater packages in openwrt 2012-04-04 05:22 and some vnc server library 2012-04-04 05:22 yes 2012-04-04 05:23 blogic has quit [#qi-hardware] 2012-04-04 05:23 oh 2012-04-04 05:23 "i need new eye" 2012-04-04 05:23 you said that :) 2012-04-04 05:24 if we find sdl vnc client, we might have a chance 2012-04-04 05:25 but then, it's just 320x240.. what is the use case you are thinking about? 2012-04-04 05:27 http://www.ferzkopp.net/Software/SDL_vnc/ - this is something really basic 2012-04-04 05:27 and old, too 2012-04-04 05:30 use case anticipates future higher resolutions :-) 2012-04-04 05:30 I've used a vnc client on framebuf before, but forgot which one it was. there are so many clients... 2012-04-04 05:30 http://svn.icculus.org/palantir/trunk/ - this is another sdl vnc client 2012-04-04 05:31 ah, directvnc 2012-04-04 05:31 that was the one I used 2012-04-04 05:31 ah looking good 2012-04-04 05:31 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 2012-04-04 05:31 not very old also 2012-04-04 05:32 directfb is probably better than sdl if it works 2012-04-04 05:38 jekhor has joined #qi-hardware 2012-04-04 05:48 kristianpaul has joined #qi-hardware 2012-04-04 06:02 DocScrutinizer: hi good morning :-) 2012-04-04 06:03 you mentioned boundary scan tests the other day, in passing with design rule checks 2012-04-04 06:03 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 2012-04-04 06:03 pabs3 has joined #qi-hardware 2012-04-04 06:03 but how about jtag boundary scans? can you describe in a bit more detail what kind of testing you had in mind? 2012-04-04 07:13 wej has joined #qi-hardware 2012-04-04 07:16 [commit] Adam Wang: correcting NC pins to Unspecified electrical type. (master) http://qi-hw.com/p/kicad-libs/b864df8 2012-04-04 07:16 [commit] Adam Wang: correct Vcc to Power input electrical type (master) http://qi-hw.com/p/kicad-libs/55ba6c9 2012-04-04 07:16 [commit] Adam Wang: added DIN_5_2S with two pin shields (master) http://qi-hw.com/p/kicad-libs/e43dcbe 2012-04-04 07:17 rejon has joined #qi-hardware 2012-04-04 08:01 wej has joined #qi-hardware 2012-04-04 08:51 wolfspraul: see http://en.wikipedia.org/wiki/Boundary_scan 2012-04-04 08:53 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). 2012-04-04 08:54 and 2012-04-04 08:54 >>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. 2012-04-04 08:55 ~wiki jtag 2012-04-04 08:55 At http://en.wikipedia.org/wiki/Jtag (URL), Wikipedia explains: "{{Refimprove|date=November 2009}} 'Joint Test Action Group' ('JTAG') is the common name for what was later standardized as the IEEE 1149.1 'Standard Test Access Port and Boundary-Scan Architecture'. It was initially devised for testing printed circuit boards using boundary scan and is still widely used for this application. Today JTAG is also widely used for IC debug ports. In the ... 2012-04-04 08:55 "Joint Test" is the keyword 2012-04-04 09:00 wolfspraul: to put it as simple as it basically is: JTAG boundary scan is a huge "cable tester" 2012-04-04 09:00 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" 2012-04-04 09:02 then you check each "wire" (aka trace / solder point) for connection and for isolation to neighbours 2012-04-04 09:04 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 2012-04-04 09:07 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 2012-04-04 09:09 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 2012-04-04 09:10 ;s/over/via/ 2012-04-04 09:32 >>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.<< 2012-04-04 09:34 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).<< 2012-04-04 09:51 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 2012-04-04 09:51 DRC* 2012-04-04 09:51 understood - have to do some background reading but I'll get to that. thanks a lot! 2012-04-04 09:52 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 2012-04-04 09:54 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 2012-04-04 09:56 then some spice-alike equation solver runs each net to check if the equation results in "good" or in "mismatch" 2012-04-04 09:57 open pins are a very interesting case for that 2012-04-04 10:00 (nifty design with tristate) usually you get a 3rd class of equation solver results: warnings 2012-04-04 10:03 "WARNING! two outputs on same trace. Mismatch for (p238:out:1 && p317:out:0), (p238:out:0 && p317:out:1) 2012-04-04 10:05 for GPIO exactly same warning 2012-04-04 10:05 for a case where one of both not tristate but totempole output, this becomes "ERROR!" 2012-04-04 10:06 same "ERROR!" if for 2 GPIO the power-on defualt of one is incompatible with power-on default of the other 2012-04-04 10:08 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 2012-04-04 10:10 the equation solver engine runs one solution for each of the pin's possible states: H, L, high-Z, input, pullup, pulldown... 2012-04-04 10:12 like with lint you'll want to "comment out" some warnings, by e.g. defining pull-up and output as illegal for a GPIO 2012-04-04 10:13 all those "lint comments" will get shipped to sw-engineers to let them know what they must avoid to ever do 2012-04-04 10:14 a good hw design has an empty such list 2012-04-04 10:17 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 2012-04-04 10:19 unless of course your properties of both pins would allow such pathological case without any violation of ABS MAX ratings for fan out 2012-04-04 10:20 (means: one of the GPIO has some "internal 50R" so it's short circuit tolerant and also won't overload the other GPIO) 2012-04-04 10:23 xiangfu has joined #qi-hardware 2012-04-04 10:23 antoniodariuh_ has joined #qi-hardware 2012-04-04 10:25 cladamw_ has joined #qi-hardware 2012-04-04 10:29 [commit] Xiangfu: nanonote-files: cleanup etc/ files (master) http://qi-hw.com/p/openwrt-packages/78095b1 2012-04-04 10:36 [commit] Xiangfu: xburst: nanonote: move Ben special files to it's package (master) http://qi-hw.com/p/openwrt-xburst/c6e40d3 2012-04-04 10:37 wolfspraul: probably quite a different approach to DRC than the trace-geometrics check we usually see in layout CAD, hm? :-) 2012-04-04 10:39 [commit] Xiangfu: nanonote-files: config.full_system: remove non-compile packages (master) http://qi-hw.com/p/openwrt-packages/4ff5437 2012-04-04 10:42 [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 2012-04-04 10:48 xiangfu: some packages you removed are actually fixed, like centerim, dgclock.. 2012-04-04 10:48 nightsky, netsurf, what else.. 2012-04-04 10:51 it probably makes sense not to remove broken packages, but rather make them =m or mark as @BROKEN in Makefile, so people woudl know 2012-04-04 10:55 kyak, oh. 2012-04-04 10:55 [commit] Xiangfu: Revert "nanonote-files: config.full_system: remove non-compile packages" (master) http://qi-hw.com/p/openwrt-packages/e3b5136 2012-04-04 10:55 [commit] Xiangfu: nanonote-files: remove nlove, jamvm, pygame. add libnl-tiny (master) http://qi-hw.com/p/openwrt-packages/83f3429 2012-04-04 10:56 i'd really prefer marking them @BROKEN, so that we know what to fix 2012-04-04 10:56 kyak, mark as @BROKEN. yes agree. 2012-04-04 10:58 kyak, but I think just remove from config.full_system and mark as @BROKEN 2012-04-04 10:58 =m is like comment :-) 2012-04-04 10:59 yeah, if you mark it as @BROKEN, =m doesn't make sense 2012-04-04 11:00 kyak, thanks. marking @BROKEN now.. 2012-04-04 11:01 kyak, I saw you update 'netsurf' a lot, cool 2012-04-04 11:02 [commit] Xiangfu: mark nlove, offrss, pygame as @BROKEN (master) http://qi-hw.com/p/openwrt-packages/5a2adbf 2012-04-04 11:02 yeah, but if you read the comment to netsurf commit, it's not quite so cool 2012-04-04 11:02 kyak, I am try to add new 'gmen2x' icons to nanonote-files. since gmenu2x have broken. :( 2012-04-04 11:03 wolfspraul: with DRC like I define it, odd quirks like the "LED eating massive current" in GTA02A5 never had crept in 2012-04-04 11:03 kyak, yes I saw the comment and 'gmenu2x' revert. :-) 2012-04-04 11:04 xiangfu: actually, it makes more sense to keep icons in nanonote-files repo rather than gmenu2x repo 2012-04-04 11:04 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 2012-04-04 11:04 gmenu2x repo is for gmenu2x development, not for new icons commits :) 2012-04-04 11:05 kyak, yes. 2012-04-04 11:05 kyak, let's do it. :-) 2012-04-04 11:05 yep! 2012-04-04 11:05 ...depending on powers of equation solver 2012-04-04 11:05 I am moving the icons now.. 2012-04-04 11:06 and if things go well with David's fancy new shell, who knows, maybe gmenu2x may as well have a rest 2012-04-04 11:08 [commit] Xiangfu: move nanonote gmen2x icons from gmen2x.git to here (master) http://qi-hw.com/p/openwrt-packages/cb90452 2012-04-04 11:09 [commit] Xiangfu: move all Ben Nanonote icons to it's nanonote-files packages (master) http://qi-hw.com/p/gmenu2x/a881e78 2012-04-04 11:12 kyak, let me stop the current build see if we can get a clean build for next release. (include all recently commits) 2012-04-04 11:12 m 2012-04-04 11:12 you need to mark gcc-mips as broken 2012-04-04 11:13 i wasn't able to get to it yet.. 2012-04-04 11:13 then probably it would all build 2012-04-04 11:14 [commit] Xiangfu: gcc-mips mark as broken (master) http://qi-hw.com/p/openwrt-packages/7eb4f78 2012-04-04 11:15 kyak, ok. the current build haved stop. let's see how next build going... 2012-04-04 11:16 xiangfu: great! 2012-04-04 11:16 the build will start in next 3 hours. those 3 hours buildhost is busy on milkymist one compile . 2012-04-04 11:16 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 2012-04-04 11:17 it looks pretty bad.. has something to do with directfb 2012-04-04 11:17 bad it somewhat works.. i typed uname -a :) 2012-04-04 11:18 xiangfu: btw, nmap and tcpdump fail to build for me.. didn't have a closer look yet 2012-04-04 11:19 we have tcpdump in full config, might cause problems.. 2012-04-04 11:19 tcpdump compile fine under build host. 2012-04-04 11:20 kyak, http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.minimal-20120402-0952/packages/tcpdump_4.2.1-1_xburst.ipk 2012-04-04 11:20 oh, ok 2012-04-04 11:20 I use a config.minimal build to check if package compile find. 2012-04-04 11:21 [commit] Xiangfu: nanonote-files: don't use manually edit config file (master) http://qi-hw.com/p/openwrt-packages/2b11c51 2012-04-04 11:21 kyak, BTW: the make kernel_menuconfig, in different system give different behavior. 2012-04-04 11:22 kyak, I think you commit is works better under buildhost. which is good. 2012-04-04 11:22 s/you/your 2012-04-04 11:22 xiangfu meant: "kyak, I think your commit is works better under buildhost. which is good." 2012-04-04 11:22 xiangfu: yeah, i remember that kernel_menuconfig was buggy, but i tried this time, and it worked just fine 2012-04-04 11:23 jekhor has joined #qi-hardware 2012-04-04 11:23 btw, what;s the difference between config.autogen and config? 2012-04-04 11:24 kyak, I manually edit some config in latest release. since there are too many package not compile in latest release. 2012-04-04 11:25 kyak, now back to normal. 2012-04-04 11:25 ah, ok 2012-04-04 11:26 kyak, have to go. see you later. 2012-04-04 11:26 see you! 2012-04-04 11:28 DocScrutinizer has joined #qi-hardware 2012-04-04 11:30 jivs_ has joined #qi-hardware 2012-04-04 11:43 GNUtoo has joined #qi-hardware 2012-04-04 11:44 cladamw has joined #qi-hardware 2012-04-04 11:45 zoltanh7211 has joined #qi-hardware 2012-04-04 11:45 Hi guys 2012-04-04 11:45 DocScrutinizer has joined #qi-hardware 2012-04-04 11:56 DocScrutinizer: (JTAG) interesting ... i always considered "Joint" an attribute of "Group", not of "Test". similar to "junta". in the sense of multi-vendor. 2012-04-04 11:56 rejon ping 2012-04-04 11:57 wpwrak: unclear 2012-04-04 11:57 for me it's "joint test" 2012-04-04 11:57 as that's basically what JTAG-BS is all about 2012-04-04 11:58 both INT (for bonding) and EXT (for solder joints) 2012-04-04 11:58 nah, not exactly< bonding 2012-04-04 11:58 bonding also is EXT 2012-04-04 11:58 obviously :-) 2012-04-04 11:58 wolfspraul ping 2012-04-04 11:59 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 2012-04-04 11:59 wpwrak: nice 2012-04-04 11:59 DocScrutinizer: or the (work in progress) qi-hw variant: http://downloads.qi-hardware.com/people/werner/tmp/out.pdf 2012-04-04 12:04 kyak: (gcc-mips broken) so that's "game over" ? :) 2012-04-04 12:05 wpwrak: if your pin types are sufficiently detailed, in a sense that BiDi(S4C4554) := GPIO_type3(1.8V,pu+pd,fan-out=8) 2012-04-04 12:05 wpwrak: no, not at all.. just everything has its time.. too many packages broke since last release 2012-04-04 12:05 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) 2012-04-04 12:05 then this is even better than declaring each and every parameter for each and every pin again 2012-04-04 12:06 kyak: ah, so it builds but some exotic features don't work ? 2012-04-04 12:06 kyak: (gcc download) that was following http://en.qi-hardware.com/wiki/Building_Software_Image 2012-04-04 12:06 wpwrak: no, it doesn't build :) not with the updated toolchain of openwrt 2012-04-04 12:06 a generic BiDi for all levels of VDD_IO of course doesn't help that much 2012-04-04 12:07 DocScrutinizer: yes, i said it's primitive ;-) 2012-04-04 12:07 new gcc version, new uClibc version, gcc-mips is broken :) 2012-04-04 12:07 wpwrak: maybe primitive but we're on same page regarding principles 2012-04-04 12:07 wpwrak: i regularly remove my dl/ dir.. didn't have the problem.. probably the mirror was down.. is it still the case? 2012-04-04 12:08 wpwrak: are you followign the "Building OpenWrt based on release files" or "Building OpenWrt on last git commmit" steps? 2012-04-04 12:08 kyak: one mirror was down, the others didn't have the directory. that's where i declared defeat :) 2012-04-04 12:09 kyak: based on release files. playing it safe :) and i used the one that explicitly gives a commit (43a86619c3cb9aceaace51097bc35d59b7b8a4fc) 2012-04-04 12:10 roh: ping 2012-04-04 12:10 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 2012-04-04 12:10 roh: what are the plans regarding svn.openmoko.org now? 2012-04-04 12:11 roh: seems quite a number of people still need it 2012-04-04 12:11 wpwrak: there is such thing.. once downloaded on buildhost, the tarball should be in http://downloads.qi-hardware.com/software/mirror-openwrt-sources/ 2012-04-04 12:12 and the build system will try to pull it from there as a last resort 2012-04-04 12:12 [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 2012-04-04 12:12 now, i wonder why linaro-4.6... if you base on a last release, it should be linaro-4.5 2012-04-04 12:13 wpwrak: how about you do it based on a last commit? :) 2012-04-04 12:14 kyak: (mirror) sounds good. but perhaps it should be used first ? after all, that's what has been tested. 2012-04-04 12:14 kyak: (linaro) ftp://ftp.uu.net/archive/systems/gnu/gcc/gcc-4.6-linaro/gcc-4.6-linaro.tar.bz2 2012-04-04 12:15 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 :) 2012-04-04 12:15 wpwrak: i think the intention is to try to download from the "official" location, then fallback to the cached mirror 2012-04-04 12:16 btw, the commit number in wiki is just an example 2012-04-04 12:16 kyak: (official) yes, but does that provide any practical benefit ? 2012-04-04 12:16 you should use the real release_ branch or find the correct hash 2012-04-04 12:18 kyak: (example) hmm. why are there so many manual steps anyway ? wouldn't a "git pull ....; make release" be possible as well ? 2012-04-04 12:18 kyak: or maybe "make toolchain". which should be one of the main reasons for wanting to go through all this anyway :) 2012-04-04 12:19 the page is about building images, i guess 2012-04-04 12:19 if you want the toolchain - just download it 2012-04-04 12:20 what do you mean by "manual steps"? 2012-04-04 12:20 [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 2012-04-04 12:21 (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 2012-04-04 12:21 erent site. 5) upstreams sometimes simply die. 2012-04-04 12:22 and 6) upstream is temporarily down 2012-04-04 12:22 for everything you have mentioned, there is a fallback mirror 2012-04-04 12:23 and also md5sum 2012-04-04 12:23 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 2012-04-04 12:23 only in case 3a there would be an advantage of preferring upstream over mirror 2012-04-04 12:24 wpwrak: could you better tell me, how to make JZ4740 FB work in 16 bpp mode? :) 2012-04-04 12:25 to avoid this horrible mess: http://downloads.qi-hardware.com/people/kyak/tmp/directvnc.png 2012-04-04 12:25 (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) 2012-04-04 12:25 directvnc doesn't support 32 bpp, JZ4740 FB doesn't support 16 bpp 2012-04-04 12:25