<rafa>
kristianpaul: if you need the package which has that it is : qt4-mkspecs
<kristianpaul>
ahh
<kristianpaul>
ggrss
<kristianpaul>
i need wmake anyway..
<kristianpaul>
qmake*
<kristianpaul>
i wonder if in can try compile it..
<kristianpaul>
argg dropbeat is easting lot of memory... buw who needs ssh with this emdebbed devices ???
<kristianpaul>
xiangfu: zear is aceptable to you consider that ssh is uncesary for the Ben, as there is no need for security and in the other replace the dropbear will give more memory and high data tranfer
<wpwrak>
kristianpaul: just say no to dropbear. like so many of those "light" programs (busybox, etc.), it has some nasty quirks if you have an even slightly more advanced use.
<zear>
what about me now?
<kristianpaul>
wpwrak: hmm
<wpwrak>
kristianpaul: "no need for security". yup, and 640 kB are enough ;-)
<kristianpaul>
llol
<zear>
ssh it the way i use to log on the nanonote (typing the commands on nn's keyboard is a suicide) and to transfer the files
<kristianpaul>
ok..
<kristianpaul>
sure all we do
<zear>
you guys want to remove ssh?
<kristianpaul>
*i* just put the idea on the table
<zear>
what do you want to replace it with? telnet?
<wpwrak>
zear: only kristianpaul does. and he'll stop doing that once he's taken his medicine :)
<wpwrak>
zear: kermit ! ;-)
<kristianpaul>
okay remove this log and onbody said nothing about ssh
<kristianpaul>
nobody*
<zear>
wpwrak, ha! One learn something new every day
<zear>
i heard something about kermit, though never really checked it out
<kristianpaul>
but i just remenber the usb gadget can emulate serial port over ethernet...
<kristianpaul>
needs his medicine
<wpwrak>
kristianpaul: if you dig deep enough, you'll even find something that multiplexes several sessions over a serial line. i think it had file transfer as well. can't remember the name, though.
<zear>
speaking about the serial port, i have this little cool thingy rafa gave me during the jlime meeting (i believe it originates from wpwrak?), though i have no skills to solder it in :P
<kristianpaul>
idbg?
<wpwrak>
kristianpaul: of course, then there's also ka9q. that was very useful on linux, before we had tcp/ip in the kernel :)
<zear>
i don't know, a little thingy with usb connector that acts like serial port for kernel output
<kristianpaul>
psk32??
<wpwrak>
kristianpaul: (idbg) no no, it's some program. i actualy used it quite a lot but that was a looong time ago. 20+ years.
<zear>
ah, you are talking about something else, nvrmnd
<kristianpaul>
idbg <- cool thingy ??
<kristianpaul>
ah i guess fdti chips kill it ;-)
<wpwrak>
kristianpaul: (ftdi) dunno. i was planning to replace the mcu with one, but considering the lousy results i got with bit-banging, i'm less confident about this.
<kristianpaul>
:-/
<kristianpaul>
you'll need a really tiny and powerfull CPLD and solve all your problems ..
<kristianpaul>
talking about bit-banging
<wpwrak>
kristianpaul: small, powerful, cheap, with lots of built-in analog components, including an LDO. yes ;-)
<kristianpaul>
:p
<kristianpaul>
hhee
<kristianpaul>
i'm finding poke very usefull
<wpwrak>
kristianpaul: ah, you've overcome your fear. very good :-)
<kristianpaul>
hey that freedom stack look bettyer with comments
<lekernel>
it's not the same...
<lekernel>
I merely copied the idea and adapted it
<kristianpaul>
i see
<mth>
speaking of events, anyone coming to t-dose tomorrow?
<kristianpaul>
networking is missing
<mth>
http://www.t-dose.org/ - open source event in Eindhoven (south-east of the Netherlands)
<wpwrak>
lekernel: don't you want to copy the design tools also into the "<< Traditional >> schematics" box ?
<lekernel>
usually when you do a schematics entry, it's for making a PCB..
<lekernel>
and there are already a lot of things to say for a 10-minute talk
<kristianpaul>
ahh thats why so short
<kristianpaul>
ok
<kristianpaul>
i was about to ask for more sldes :)
<wpwrak>
lekernel: (schem entry) yup. you could also just merge the two boxes. it's just a little odd that you duplicate the projects but not the tools.
<wpwrak>
kristianpaul: heh, me too. "where's the cool technology ?" ;-)
<lekernel>
mh?
<lekernel>
what do you want to see, exactly? :)
<kristianpaul>
well on my side i would like an quick SoC review
<kristianpaul>
not too much tenical just the concept
<wpwrak>
lekernel: nice ! let's hope you can recruit some contributors. we're still quite weak in the mechanical area. the only tangible results so far are the counterweights, a few PCBs, and Jane's bags.
<kristianpaul>
also for the Milkydrop part
<lekernel>
kristianpaul, i'll demonstrate that anyway (exhibition, and talk if I have spare time)
<kristianpaul>
well latelly USB development deservers a slide
<kristianpaul>
lekernel: sure
<lekernel>
USB is a detail (and USB sucks)
<kristianpaul>
ok lets swich USB by RTEMS as sofware parts is requiren help
<kristianpaul>
:-)
<kristianpaul>
s/requiren/requiring
<wpwrak>
lekernel: some feature list would be nice. it doesn't have to be very understandable, just impress :)
<kristianpaul>
yeah
<lekernel>
RTEMS is 80% done by now
<lekernel>
it's not uClinux, you can move fast :)
<wpwrak>
lekernel: (feature list) but if there's no time, you can just put such a list in the exhibition area. people will probably stroll by anyway.
<lekernel>
yeah
<kristianpaul>
what people most asked you first about the MM One lekernel ?
<wpwrak>
"does it run linux ?" (-:C
<lekernel>
no, price and availability
<lekernel>
anyway for the "does it run linux" as long as they see busybox and /proc/cpuinfo they're happy
<kristianpaul>
hehe
<lekernel>
i even get extra points for running it on the framebuffer console :)
<lekernel>
but under this appearance, the uClinux port really sucks
<kristianpaul>
ahh cool, on flickernoise you did it?
<wpwrak>
in what way does it suck ?
<kristianpaul>
unknow reboots?
<kristianpaul>
slwo?
<kristianpaul>
slow*
<lekernel>
by my standards at last, theobroma systems (who did the original port to the LM32 arch for lattice, in which we fixed many issues already) says it's "production grade"
<lekernel>
dirty code
<lekernel>
missing drivers
<lekernel>
bugs
<lekernel>
unstability
<lekernel>
missing features
<kristianpaul>
heh better replace it ..
<wpwrak>
is this because of uclinux or just because of the port ?
<lekernel>
because of uclinux and gnu
<kristianpaul>
lol
<kristianpaul>
ok but RTEMS uses gnu and works better, isnt?
<wpwrak>
see rms, that's what you get for insisting on gnu/linux - now people blame you for the linux bugs as well ;-)
<kristianpaul>
haha
<lekernel>
there are probably 10 persons on earth who understand the binutils/gcc source...
<lekernel>
and when those pieces of crap break (as they often do when targeting lm32 uclinux) you're left with a huge mess that you need to fix
<kristianpaul>
lets invite one of then to join your project !
<wpwrak>
rumor has it that gcc used to be an even bigger mess in the not too distant past ...
<kristianpaul>
:_/
<kristianpaul>
sofware is gas as somebody else said..
<lekernel>
oh, and i'll spare you the details of building a software package that uses autoconf and libtool for lm32 uclinux...
<wpwrak>
lekernel: you're preaching to the choir ;-)
<lekernel>
sometimes it's faster to throw that junk away and simply run gcc *.c -o executable
<lekernel>
that's just ridiculous
<wpwrak>
is a card-carrying member of the autotools haters club
<lekernel>
too
<wpwrak>
lekernel: only sometimes ? :)
<lekernel>
yes, because sometimes the GNU/Autocrap needs to generate a config.h that is later included by the program
<lekernel>
those programs are the worst to port
<wpwrak>
seems that you need an autotools-hugger to join and clean up stuff, so that things will be easier in the future
<wpwrak>
so don't talk too badly about it :)
<lekernel>
well
<lekernel>
I made my decision
<lekernel>
I switched over to RTEMS :)
<lekernel>
everything went much smoother since then
<wpwrak>
NIH labs proudly present .... :)
<lekernel>
mh?
<wpwrak>
Not Invented Here
<lekernel>
haha, no, there are technical reasons
<wpwrak>
seems that my function generator is accurate to about 1 ppm. i like that :)
<lekernel>
and rtems isn't even that exotic
<wpwrak>
lekernel: still .. think of the thousands of packages, say, jlime has. that's still a very long way.
<wpwrak>
lekernel: so we should get rafa a MM1 board. then he can solve the obstacles that prevent jlime from building there.
<lekernel>
sure, that's why I leave it to other people (and not myself alone) the care of porting them and beating autocrap/linux/gcc into place
<wpwrak>
rafa, how about learning a bit of gcc, binutils, and autotools internals ? ;-)
<wpwrak>
(well, you probably had your share of fun with autotools already :)
<lekernel>
besides, linux and x11 are slow
<lekernel>
quite frankly, the few successful Linux ports that i've seen have been done by companies like Codesourcery
<lekernel>
who probably benefit a lot from the GNU obscurantism :)
<wpwrak>
hmm. if you get linux to compile and run, your toolchain can't be all bad.
<lekernel>
ok. then, what would you use as GUI toolkit?
<rafa>
wpwrak: sorry, to learn for what? I am not following
<wpwrak>
lekernel: whatever works ? :) personally, i like gtk, because it plays nicely with C
<lekernel>
but requires a bunch of crazy dependencies: glib, cairo, x11, ...
<wpwrak>
rafa: learn about the dark side of gcc and friends to port jlime to the milkymist processor :)
<rafa>
wpwrak: ah.. no following.. so there is not a gcc for milymist processor¡?
<wpwrak>
lekernel: but how many of those things are really a problem one you've properly debugged your toolchain ?
<wpwrak>
s/one/once/
<kristianpaul>
rafa: it is
<lekernel>
well, first they're slow
<kristianpaul>
rafa: just current uclinux for milkymist seems to lack features plus bugs, and aparently noo usabillity
<lekernel>
then, how would you integrate support for graphics acceleration like the texturing unit?
<lekernel>
when I see the mess the DRI is, I do not want to touch it
<wpwrak>
lekernel: that's an optimization problem :) first, i'd be interested in the 99% of the applications where i don't really care about performance
<rafa>
lekernel: x11 slow: it depends that you mean with slow.. it looks for me that x11 is a generic word for a huge world of programs doing xwindow.. And I have found xfbdev fast enough many times against porting applications to fb directly..
<mth>
lekernel: I thought Gallium was the future of graphics acceleration
<mth>
or is that layered on top of DRI?
<lekernel>
both seem equally unappealling to me
<lekernel>
keep thing simple...
<mth>
but graphics hardware today is not simple
<lekernel>
mine is :)
<mth>
you can make a specific API for your hardware of course, but then there won't be much software for it
<wpwrak>
lekernel: milkymist can be different things to different people. e.g., i usually don't care much about graphics performance. but the ability to synthesize peripherals that connect efficiently to the rest of the system would be very exciting.
<rafa>
wpwrak: if lekernel needs a GUI without X then I would vote for SDL :) .. well, it is not a GUI to do windows/buttons.. but you can easily to use it for that and write a small lib
<mth>
if you want to do windowing, consider DirectFB
<mth>
you can even run wxWidgets or GTK on top of DirectFB
<lekernel>
I already have a GUI library that does windowing, buttons, widgets, etc.
<mth>
and DirectFB can use hardware specific acceleration if you write some driver code for it
<wpwrak>
rafa: yeah, and people have done amazing things on top of SDL. i always thought it was little more than just a frame buffer, but boy was i wrong.
<lekernel>
and is many times faster than a wxwidgets+gtk+cairo+glib+directfb+sdl+fb bloatstack
<wpwrak>
lekernel: ah yes, wxGTK ;-)
<lekernel>
but well, if someone wants to run Linux, perfect!
<lekernel>
I'm all for it
<mth>
lekernel: wxWidgets + DirectFB is a pretty light stack
<lekernel>
I just do not want to waste my personal time on it
<lekernel>
it's a huge effort, bigger than reinventing some wheels
<mth>
you can always get something lighter if you write everything yourself, but I'm not sure the difference is worth the effort
<lekernel>
and a dirty job when it comes to fix the software from the GNUtards
<kristianpaul>
sure not you lekernel send a board to rafa ;-)
<lekernel>
you don't need a board for the linux port, there's QEMU available for that
<kristianpaul>
true
<wpwrak>
lekernel: there's a big difference between qemu and a real device when it comes to motivation ...
<rafa>
lekernel: how do you know that your lib is faster than sdl for example?.. I mean.. maybe I am not following the whole chat here.. but it seems that you just have your GUI and no linux there?.. How is the comparison?
<lekernel>
if there's isn't enough motivation already to overcome using QEMU in a first time, I doubt there will be enough when it'll come to fight with the GNU tools
<kristianpaul>
actually more for the visual tasks i agree with wpwrak
<kristianpaul>
rafa: i think there is no comparison yet
<lekernel>
kristianpaul, oh, I did get SDL apps to run on Linux
<lekernel>
did you forget those mails already?
<kristianpaul>
no
<lekernel>
my initial plan was even to use uClinux and SDL
<rafa>
kristianpaul: is uclinuc the thing used with openwrt?
<rafa>
(as well)
<wpwrak>
rafa: could you mean uclibc ?
<rafa>
wpwrak: probably. .. dont know much about openwrt, so it was ulibc surely :)
<rafa>
uclibc
<wpwrak>
rafa: uclinux is a variant of the linux kernel that doesn't need an MMU.
<wpwrak>
lekernel: perhaps it would help things if you could add some really simple MMU ? could be a throwaway design, just to get things rolling. that way, the system would be "more mainstream", so you'd avoid a number of pitfalls that certainly exist outside the beaten path.
<rafa>
wpwrak: ah.. yes, then uclibc is the thing I remember from qi ml :)
<wpwrak>
lekernel: (of course, after ccc ... :)
<lekernel>
yeah, I could do that and what not, if I had 72-hour days
<lekernel>
though I won't reject a patch that implements a MMU
<lekernel>
my view on the question is that GNU/Linux is a huge and dirty effort that is better shared and put on as many shoulders as possible
<wpwrak>
lekernel: i'd love to help with an mmu patch, but i still have that open source synthesis toolchain in my dependency graph ... seems that none of your future selves has invented time travel, or you'd already have the code somewhere :)
<lekernel>
I won't touch it unless I have an army of 100 motivated developers
<wpwrak>
lekernel: (many shoulders) it's a huge effort, that's for sure. so anything that makes it easier for people to get going is good.
<lekernel>
and if I were to port an Unix-like OS from scratch myself, I'd rather choose NetBSD
<lekernel>
assuming I have a MMU
<kristianpaul>
rafa: yes libc suck for emdebbed a bit ;-) i was told that
<lekernel>
I'm just too tired of the shitty technical quality of GNU/Linux
<lekernel>
open source synthesis toolchain: that's something I find way more interesting than fixing GNUtarded software :)
<rafa>
kristianpaul: can you tell me who told you that? you often say "i was told that".. and many time I do not agree :D
<rafa>
kristianpaul: BTW, you mean uclibc, or libc?
<rafa>
kristianpaul: do you remember the wpwrak tests of speed? jlime seemed a lot faster than openwrt.. and it uses libc (jlime). But well, I am not saying here that it is the reason why jlime was faster
<kristianpaul>
rafa: was a guying working on the early port for the avr32 cpu in openwrt
<wpwrak>
lekernel: excellent. there are lots of people out there who can make autotools behave, but there are very few who can do the open synthesis toolchain :)
<rafa>
kristianpaul: but that is something which both distros could differ
<wpwrak>
rafa: my speed test was flawed. (i think because of gmenu2x messing with the clock, but i'm not entirely sure.) in the end, they're about the same.
<kristianpaul>
rafa: agreed, i think you are more experienced on that field to give a comment, this guy surelly was just complaining
<rafa>
wpwrak: somebody did the test without gmenu2x as well IIRC
<wpwrak>
rafa: btw, when you say "glibc", do you really mean "glibc" or "eglibc" ? according to christoph, glibc is a dead end
<rafa>
wpwrak: (we did a few tests on #jlime, so I should check my logs)
<rafa>
wpwrak: christoph always giving nice news ;-))
<wpwrak>
rafa: (memcpy speed) i don't quite remember the details. just that the difference largely disappeared in the end.
<wpwrak>
rafa: (glibc dead end) the reasons being precisely that it's too bloated and so on. apparently, most major distributions have switched to eglibc.
<rafa>
wpwrak: eglibc is the thing
<rafa>
wpwrak: the confussion for me is that the package is named libc6, but it is eglibc
<wpwrak>
rafa: yeah, for compatibility :)
<kristianpaul>
Hey i like this conding style in SIE sram example :°)
<wpwrak>
someone distrusts his C compiler a lot more than even lekernel distrusts gcc ;-)
<kristianpaul>
:p
<kristianpaul>
well not so simple
<kristianpaul>
i dint noticed that line yet...
<kristianpaul>
what ever it does?....
<kristianpaul>
wpwrak: i'm at src folder ATM
<kristianpaul>
he better i dint looked and build :p
<kristianpaul>
ha ! thats ingenic code
<wpwrak>
ah, right :) maybe wolfgang can bring them a C book as a present for the next visit :) the code looks nice in general, but there are a few spots where it looks deeply confused
<lekernel>
hahaha, glibc
<lekernel>
another reason for me to dislike GNU
<lekernel>
just look at the bug reports and patches and how they're answered... LOL
<wpwrak>
lekernel: glibc is dying. long live eglibc ! :)
<kristianpaul>
will this happen to gcc? ...
<kristianpaul>
s/wil/may
<kristianpaul>
lekernel: had you ever consider minix3 for the MM?
<wpwrak>
hmm, if this is for gcc, better to use inline instead of #define
<kristianpaul>
ah sure
<kristianpaul>
but gets an idea and could save me read manual pages
<wpwrak>
(inline) because the p and o can cause stray warnings with -Wshadow. otherwise, this looks good. of course,  foo = (1 << o);  ought to be  foo = 1 << o;
<wpwrak>
actually, 1 << (o) :-)
<wpwrak>
at least while it's a macro
<lekernel>
minix3 needs a MMU
<kristoffer>
lekernel, how is the feeling of minix3 btw? been awhile since I tested it
<lekernel>
it seems pretty good
<kyak>
NAND DATA partition offset is incorrect now