Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
Jay7 has joined #qi-hardware
cladamw has joined #qi-hardware
<pabs3>
DocScrutinizer: glamo docs are fully public now, Sean got permission to release them
<pabs3>
(well, unless there are some he didn't have or forgot about)
<wolfspraul>
pabs3: have you developed for fpgas? which opencores cores have you found usable?
<pabs3>
no
<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 :-)
<kristianpaul>
indeed, i havent time to look at opencores, perhpas the ethernet and usb ones.. but ... nah to lazy to compare
<pabs3>
given that Linux supports OpenRISC now, I guess something from there is working
<kristianpaul>
it works indeed
<kristianpaul>
and openrisc SoC is a fact for that
<kristianpaul>
indeed
<wolfspraul>
have either of you tried it?
<roh>
hey wolfspraul
* kristianpaul
waiting stekern release its openrisc port to M1..
<roh>
got my mail?
<wolfspraul>
kristianpaul: yep :-)
<wolfspraul>
that would be great
<wolfspraul>
pabs3: do you have a url for "linux supports openrisc"?
<wolfspraul>
who is using it? have they documented their work?
* pabs3
goes looking
<wolfspraul>
of course I know these statements for months, years. but a lot seems to be just hearsay.
<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 :-)
<wolfspraul>
pabs3: let's find users and documentation
<wolfspraul>
that would help us and/or stekern
<wolfspraul>
if it's open and it works, anybody should be able to use it
<wolfspraul>
roh: yes, got it - thanks!
<roh>
wolfspraul: hope you can meet. nice guy (mitch)
<kristianpaul>
pabs3: fyi stekern is a guy at #milkymist that hack around openrisc and its SoC
<wolfspraul>
fact is this:
<wolfspraul>
milkymist soc runs today, and afaik nothing stops us from replacing the lm32 core with an openrisc core
<wolfspraul>
except for 'a little' work :-)
<kristianpaul>
little, ha ;)
<kristianpaul>
well..
<wolfspraul>
but for some reason Sebastien says the lm32 core is superior, and there must be a reason for that
wej has joined #qi-hardware
<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
<wolfspraul>
or: fire up your code editor :-)
<wolfspraul>
I also hear that opencores has a 'great' 'linux supported' usb controller
<kristianpaul>
lm32 has its advantages yes, plus still small and not bad documented i think
<wolfspraul>
I try to follow opencores with the best intention for years, read their newsletter, browse projects, etc.
<wolfspraul>
but somehow it doesn't translate into reality
<wolfspraul>
but let's see
<wolfspraul>
stekern is our hope
<wolfspraul>
and maybe pabs3 buys a m1 soon and starts opencores hacking
<wolfspraul>
it's one thing that a developer sayss "this works great", or 100 or 1000 users actually agree with him :-)
<wolfspraul>
that's an entirely different thing in my experience
<wolfspraul>
like night and day - *that* different
<wolfspraul>
pabs3: does this make sense? let's start to *use* opencores stuff!
<pabs3>
indeed
<wolfspraul>
not just point to it, that's no news for years
<wolfspraul>
when we use it, we find out what really works
<pabs3>
personally I don't have the time nor disposable income to start working on that though
<wolfspraul>
we find out the nasty little details that make all the difference
<wolfspraul>
sure sure
<wolfspraul>
I did not in any way want to dismiss your input
<wolfspraul>
maybe one day you find the time and excitement
<pabs3>
understood :)
<wolfspraul>
opencores is great
<wolfspraul>
we all love it
<kristianpaul>
milkymist uses conbus core from it !
<wolfspraul>
but so far I think not 1 line of any opencores core is running on m1
<wolfspraul>
why?
<wolfspraul>
strange
<wolfspraul>
AH!
<wolfspraul>
there you go
<kristianpaul>
wich is the thing glue all soc comunication :)
<wolfspraul>
kristianpaul: do you have a url into the opencores site to the original conbus?
<kristianpaul>
sure
<wolfspraul>
I mean the one that m1 reuses/uses
<wolfspraul>
I want to build more of those connections, make people understand where things come from so they can find more...
<wolfspraul>
I repeatedly hear 'openrisc' and also 'usb controller'
<kristianpaul>
well, the version is not the same, but that one in milkmist re-use most of the code i remenber
<wolfspraul>
kristianpaul: how much was the code changed when being brought over to m1?
<kristianpaul>
20-30% i bet
<kristianpaul>
havent dont full comparison
<wolfspraul>
that's the one thing in cores land that still confuses me
<wolfspraul>
how can people work together, and benefit from each others work
<wolfspraul>
is the m1 'fork' (?) of conbus known to the original conbus devs?
<wolfspraul>
do they care?
<kristianpaul>
i think i wrote him..
<kristianpaul>
but never got reply..
<wolfspraul>
are cores mostly a one-time heoric effort without much reuse or long-term value?
<kristianpaul>
then i find answer my self trought milkymist version ;)
<wolfspraul>
nice that you tried to establish contact
<wolfspraul>
no reply, oh well :-)
* pabs3
goes to idle on #opencores
<kristianpaul>
pabs3: also sebastien sent back to opencores some cores from milkymist, the memory controller and navre (usb soft core=
<kristianpaul>
pabs3: no no
<kristianpaul>
too alone :)
<kristianpaul>
really :)
<wolfspraul>
I think the typical 'open core' (not a pun on opencores) is buggy like hell
<wolfspraul>
there are too few devs
<wolfspraul>
no quality standards
<wolfspraul>
no standardized test environments
<wolfspraul>
no expectation of reuse even, which makes devs even more reluctant to invest their time in reusability
<wolfspraul>
too many subtle details in different fpgas, even fpga generations, asic
<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
<wolfspraul>
buggy vendor toolchains working against any efforts for better long-term quality and reusability
<wolfspraul>
more? :-)
<wolfspraul>
kristianpaul: would you agree?
<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
<wolfspraul>
testing in general is under-appreciated in open cores
<kristianpaul>
yeah i know.. :-|
<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...
<wolfspraul>
actually the problem is not infinite, not at all
<kristianpaul>
also i followed opencores for while, until found you guys :D
<wolfspraul>
but there are *a lot* of shaky foundations right now, quicksand
<kristianpaul>
cores with a SoC. well...
<wolfspraul>
from a quality perspective, I think opencores is just a random assortment of all sorts of code snippets
<wolfspraul>
I think that's fair to say, althouhg I also don't know how to do better
<kristianpaul>
lets wait stekern news hopefully will give us better info about all this
<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
<wolfspraul>
kristianpaul: definitely :-)
<wolfspraul>
but most likely stekern will run into lots of nasty details
<wolfspraul>
on the surface it looks easy, but then...
<wolfspraul>
will he work through all of them? why?
<wolfspraul>
maybe just a few quick hacks enough for a demo or to say 'it works', then move to greener lands?
<kristianpaul>
to benchmark, that 'boring' need to be done anyway no?
<wolfspraul>
it's a chicken-egg problem
<kristianpaul>
hehe it works hacks :)
<wolfspraul>
no culture of reuse
<wolfspraul>
no investment in resuability
<wolfspraul>
reusability
<kristianpaul>
fully agree, on that one
<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
<wolfspraul>
and invest in high-quality documentation and testing
<wolfspraul>
until hopefully one day the real reuse and feed back cycle starts
<wolfspraul>
that's how I see it
<kristianpaul>
hmm may be we need first list SoC currently using wishbone and wishbone-like cores, plus compare what from opencores too
<wolfspraul>
would be good to do that on wikipedia though
<wolfspraul>
I'm editing milkymist-related information in wikipedia sometimes, as I learn. but could do more.
<wolfspraul>
there was also a port of milkymist soc to altera
<wolfspraul>
very exciting stuff imho
<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"
<wolfspraul>
one code tree
<wolfspraul>
one set of documentation
<kristianpaul>
oh, i need to dollow the editing of that article more often
<wolfspraul>
would be cool, but lots of work and again: why do it? if nobody reuses anyway :-)
<kristianpaul>
s/dollow/follow
<qi-bot>
kristianpaul meant: "oh, i need to follow the editing of that article more often"
<wolfspraul>
lemme see, at least the url
<wolfspraul>
trying to build bridges :-)
<wolfspraul>
painful to build a bridge when nobody cares to use it anyway
<wolfspraul>
you rather just use a boat to cross the river once, for yourself
<wolfspraul>
great, can't even find in the README :-)
<wolfspraul>
and (*zero* blame to william here), there is not much effort to merge activities, or at least document/learn from each other
<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.
<wolfspraul>
that is already pioneering work!
<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.
<wolfspraul>
I think I must have seen this 10 times now with bits and pieces from milkymist, over the last 2 years.
<wolfspraul>
painful :-)
<wolfspraul>
so much wasted knowledge
<wolfspraul>
kristianpaul: you think cyclone III?
<wolfspraul>
seems he mentioned DE2_115
<kristianpaul>
ah, thats cyclone II i remenber
<kristianpaul>
no no
<kristianpaul>
argh, anywyay
<wolfspraul>
what I find looks like Cyclone IV EP4CE115
<kristianpaul>
oh much better
<kristianpaul>
he also i wodering now if he run on to routing problems..
<kristianpaul>
need to as
<kristianpaul>
k
<wolfspraul>
wow that chip alone costs about 400 USD
<wolfspraul>
we have such great value on m1!
<kristianpaul>
;)
<wolfspraul>
super high performance at low chip cost, and full focus on the open cores
<wolfspraul>
then we have noone but ourselves to blame :-)
<wolfspraul>
and the devkit sells for 300 USD :-)
<wolfspraul>
the de2-115 one
<wolfspraul>
I need to register/login with opencores to even view the sources?
<wolfspraul>
those kinds of things make me wonder about the platform, better move the sources to github even
<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).
<DocScrutinizer>
and
<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.
<DocScrutinizer>
~wiki jtag
<infobot>
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 ...
<DocScrutinizer>
"Joint Test" is the keyword
<DocScrutinizer>
wolfspraul: to put it as simple as it basically is: JTAG boundary scan is a huge "cable tester"
<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"
<DocScrutinizer>
then you check each "wire" (aka trace / solder point) for connection and for isolation to neighbours
<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
<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
<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
<DocScrutinizer>
;s/over/via/
<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.<<
<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).<<
<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
<DocScrutinizer>
DRC*
<wolfspraul>
understood - have to do some background reading but I'll get to that. thanks a lot!
<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
<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
<DocScrutinizer>
then some spice-alike equation solver runs each net to check if the equation results in "good" or in "mismatch"
<DocScrutinizer>
open pins are a very interesting case for that
<DocScrutinizer>
(nifty design with tristate) usually you get a 3rd class of equation solver results: warnings
<DocScrutinizer>
"WARNING! two outputs on same trace. Mismatch for (p238:out:1 && p317:out:0), (p238:out:0 && p317:out:1)
<DocScrutinizer>
for GPIO exactly same warning
<DocScrutinizer>
for a case where one of both not tristate but totempole output, this becomes "ERROR!"
<DocScrutinizer>
same "ERROR!" if for 2 GPIO the power-on defualt of one is incompatible with power-on default of the other
<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
<DocScrutinizer>
the equation solver engine runs one solution for each of the pin's possible states: H, L, high-Z, input, pullup, pulldown...
<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
<DocScrutinizer>
all those "lint comments" will get shipped to sw-engineers to let them know what they must avoid to ever do
<DocScrutinizer>
a good hw design has an empty such list
<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
<DocScrutinizer>
unless of course your properties of both pins would allow such pathological case without any violation of ABS MAX ratings for fan out
<DocScrutinizer>
(means: one of the GPIO has some "internal 50R" so it's short circuit tolerant and also won't overload the other GPIO)
<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
<kyak>
xiangfu: some packages you removed are actually fixed, like centerim, dgclock..
<kyak>
nightsky, netsurf, what else..
<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
<kyak>
yeah, but if you read the comment to netsurf commit, it's not quite so cool
<xiangfu>
kyak, I am try to add new 'gmen2x' icons to nanonote-files. since gmenu2x have broken. :(
<DocScrutinizer>
wolfspraul: with DRC like I define it, odd quirks like the "LED eating massive current" in GTA02A5 never had crept in
<xiangfu>
kyak, yes I saw the comment and 'gmenu2x' revert. :-)
<kyak>
xiangfu: actually, it makes more sense to keep icons in nanonote-files repo rather than gmenu2x repo
<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
<kyak>
gmenu2x repo is for gmenu2x development, not for new icons commits :)
<xiangfu>
kyak, yes.
<xiangfu>
kyak, let's do it. :-)
<kyak>
yep!
<DocScrutinizer>
...depending on powers of equation solver
<xiangfu>
I am moving the icons now..
<kyak>
and if things go well with David's fancy new shell, who knows, maybe gmenu2x may as well have a rest
<xiangfu>
kyak, BTW: the make kernel_menuconfig, in different system give different behavior.
<xiangfu>
kyak, I think you commit is works better under buildhost. which is good.
<xiangfu>
s/you/your
<qi-bot>
xiangfu meant: "kyak, I think your commit is works better under buildhost. which is good."
<kyak>
xiangfu: yeah, i remember that kernel_menuconfig was buggy, but i tried this time, and it worked just fine
jekhor has joined #qi-hardware
<kyak>
btw, what;s the difference between config.autogen and config?
<xiangfu>
kyak, I manually edit some config in latest release. since there are too many package not compile in latest release.
<xiangfu>
kyak, now back to normal.
<kyak>
ah, ok
<xiangfu>
kyak, have to go. see you later.
<kyak>
see you!
DocScrutinizer has joined #qi-hardware
jivs_ has joined #qi-hardware
GNUtoo has joined #qi-hardware
cladamw has joined #qi-hardware
zoltanh7211 has joined #qi-hardware
<zoltanh7211>
Hi guys
DocScrutinizer has joined #qi-hardware
<wpwrak>
DocScrutinizer: (JTAG) interesting ... i always considered "Joint" an attribute of "Group", not of "Test". similar to "junta". in the sense of multi-vendor.
<zoltanh7211>
rejon ping
<DocScrutinizer>
wpwrak: unclear
<DocScrutinizer>
for me it's "joint test"
<DocScrutinizer>
as that's basically what JTAG-BS is all about
<DocScrutinizer>
both INT (for bonding) and EXT (for solder joints)
<kyak>
wpwrak: no, it doesn't build :) not with the updated toolchain of openwrt
<DocScrutinizer>
a generic BiDi for all levels of VDD_IO of course doesn't help that much
<wpwrak>
DocScrutinizer: yes, i said it's primitive ;-)
<kyak>
new gcc version, new uClibc version, gcc-mips is broken :)
<DocScrutinizer>
wpwrak: maybe primitive but we're on same page regarding principles
<kyak>
wpwrak: i regularly remove my dl/ dir.. didn't have the problem.. probably the mirror was down.. is it still the case?
<kyak>
wpwrak: are you followign the "Building OpenWrt based on release files" or "Building OpenWrt on last git commmit" steps?
<wpwrak>
kyak: one mirror was down, the others didn't have the directory. that's where i declared defeat :)
<wpwrak>
kyak: based on release files. playing it safe :) and i used the one that explicitly gives a commit (43a86619c3cb9aceaace51097bc35d59b7b8a4fc)
<DocScrutinizer>
roh: ping
<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
<DocScrutinizer>
roh: what are the plans regarding svn.openmoko.org now?
<DocScrutinizer>
roh: seems quite a number of people still need it
<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 :)
<kyak>
wpwrak: i think the intention is to try to download from the "official" location, then fallback to the cached mirror
<kyak>
btw, the commit number in wiki is just an example
<wpwrak>
kyak: (official) yes, but does that provide any practical benefit ?
<kyak>
you should use the real release_ branch or find the correct hash
<wpwrak>
kyak: (example) hmm. why are there so many manual steps anyway ? wouldn't a "git pull ....; make release" be possible as well ?
<wpwrak>
kyak: or maybe "make toolchain". which should be one of the main reasons for wanting to go through all this anyway :)
<kyak>
the page is about building images, i guess
<kyak>
if you want the toolchain - just download it
<kyak>
what do you mean by "manual steps"?
<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
<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
<wpwrak>
erent site. 5) upstreams sometimes simply die.
<wpwrak>
and 6) upstream is temporarily down
<kyak>
for everything you have mentioned, there is a fallback mirror
<kyak>
and also md5sum
<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
<wpwrak>
only in case 3a there would be an advantage of preferring upstream over mirror
<kyak>
wpwrak: could you better tell me, how to make JZ4740 FB work in 16 bpp mode? :)
<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)
<kyak>
directvnc doesn't support 32 bpp, JZ4740 FB doesn't support 16 bpp
<wpwrak>
looks pretty :)
<wpwrak>
ah no, i don't know offhand how to change the color depth. trial and error are your friends ;-)
<kyak>
trial and error and, probably, larsc :)
<wpwrak>
(mirror) or perhaps there could be some option to change the order ? ideally, it would default to picking the local mirror first :)
<roh>
kyak: there are many colorspaces in 16 and 32bit as well
<kyak>
larsc: do you have an idea how to make JZ4740 FB work in 16 bit mode?
<kyak>
wpwrak: of course there is an "option" :) in scripts/download.pl
<kyak>
roh: what do you mean?
<roh>
byte-order, color depth
<roh>
32bit can be 24bit padded, with alpha... different orders
<roh>
16bit can be 565 or sth. else, different orders...
<roh>
there are many ways to use 16 or 32bit for encoding colors
<wolfspraul>
it's just a few lines, and did the trick on a notebook I setup a little while back
<kyak>
hm
<kyak>
something has definitely changed
<kyak>
it is full screen now, but still mangled
wpwrak has joined #qi-hardware
zoltanh7211 has joined #qi-hardware
<zoltanh7211>
re
<zoltanh7211>
wolfspraul ping
rejon_ has joined #qi-hardware
<zoltanh7211>
rejon ping
rejon has joined #qi-hardware
kilae has joined #qi-hardware
emeb has joined #qi-hardware
kilae has joined #qi-hardware
kilae has joined #qi-hardware
<kyak>
mth: there is another regression in gmenu2x (also somewhere around these commits).. the "workdir" parameter in icon file is ignored
<kyak>
ah, i read "Removed ability to configure custom working directory."
<kyak>
well yeah.. it turns out to be useful
<kyak>
like when we launch ash from gmenu2x, we want it to change to home dir
<kyak>
it's ugly when it starts in /usr/bin
<wpwrak>
kyak: use a wrapper script ?
<kyak>
wpwrak: frankly speaking, i don't want to.. the icon file itself is already a "wrapper"
<wpwrak>
i woud seem to be
<wpwrak>
let's try this again
<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 :)
<wpwrak>
but of course, i can't make you like it :)
<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.
<mth>
kyak: is it just ash that has this problem or more programs?
<mth>
currently gmenu2x is rather difficult to maintain and use, mostly because it has dozens of features
<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
Aylax has joined #qi-hardware
zrafa has joined #qi-hardware
<kyak>
mth, wpwrak: i understood and agree with your points.. indeed, the cleaner gmenu2x's code, the better for us.
<whitequark>
DocScrutinizer: what do you think about the article?
wej has joined #qi-hardware
Aylax has joined #qi-hardware
jekhor has joined #qi-hardware
<DocScrutinizer>
indeed lol, regarding it does full pearl regex but implicitly assumes /g
<DocScrutinizer>
umm, this article... coreboot, ChromeOS... errr :-S
<whitequark>
what?
<DocScrutinizer>
hm?
uwe_ has joined #qi-hardware
<whitequark>
what's with it?
<whitequark>
I thought coreboot was a good project
<DocScrutinizer>
well, probably it is
<DocScrutinizer>
though I'm not sure if it's just another BIOS, or that nonsensical bios based mp3 player
<whitequark>
err, a FOSS BIOS
<whitequark>
no idea what mp3 player you're talking about
<DocScrutinizer>
there's a BIOS that does media and stuff without any OS booting
<DocScrutinizer>
sure a FOSS BIOS is a nice thing
jekhor has joined #qi-hardware
capiscuas has joined #qi-hardware
LunaVorax has joined #qi-hardware
viric has joined #qi-hardware
<GNUtoo>
it's a very nice thing, I did the port on my desktop mainboard
<wpwrak>
kyak: (toolchain) thanks ! for now i'm good. i'll probably give it another try in a week or so.
zoltanh7211 has quit [#qi-hardware]
dvdk has joined #qi-hardware
<dvdk>
hmm, mplayer segfaults in uclibc
wpwrak has joined #qi-hardware
<dvdk>
hmm, have to disable freetype support in mplayer, to make it run with 'fbdev' output. accelerated output still crashing, though
<dvdk>
correction, mplayer crashes somewhere in /lib/ld-uClibc-0.9.33.so, wtf?
<wolfspraul>
how good is our debugging on the Ben setup actually?
<dvdk>
well, not at all? :)
<wolfspraul>
should we auto-build images or packages with debug info turned on?
<dvdk>
wolfspraul: debug info is not kept on nanonote, but on build system.
<wolfspraul>
and how would one be able to capture that then in case of a crash?
<wolfspraul>
yeah, I know it's tedious, so wondering
<wolfspraul>
every time there is a crash it's like the world stops :-)
<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
<dvdk>
well, currently i'm debugging with gdb but without debug info. assembler dumps plus checking memory mapping
<dvdk>
currently the easiest way is to recompile a buggy package with debug info, then test that.