<nebajoth> oh dear
<nebajoth> this is fun
<nebajoth> I'm running 2.6.32.10
<nebajoth> has anybody compiled a working kernel for the nanonote that uses a more recent kernel?
<nebajoth> I remember seeing the mailing list discussions regarding official inclusion
<nebajoth> in the mainline, that is
<nebajoth> ah yes, as of 2.6.36
<wolfspraul> yes definitely there are more recent kernels, 34/35. but I don't know exactly where the patches are or how to build them. I'd say you need to look in openwrt upstream.
<wolfspraul> everything based on the openwrt backfire release will stay with 32
<nebajoth> that's fine
<nebajoth> I'm just going to work out how to build it then
<wolfspraul> 36 should have a lot of Ben NanoNote stuff mainline, but not everything
<wolfspraul> maybe one or two drivers are still missing, mmc if I recall
<nebajoth> ls
<nebajoth> haha
<nebajoth> WRONG CMD LINE
<nebajoth> just looking at the patch
<nebajoth> the one linus merged
<nebajoth> looks like mmc is there
<nebajoth> I think
<nebajoth> but I don't see anything for audio
<qi-bot> [commit] Werner Almesberger: A new try at config.h management: moved it to ../common, along with io.h http://qi-hw.com/p/ben-wpan/57f3427
<qi-bot> [commit] Werner Almesberger: Generate port, bit, and output mode definitions from io.h http://qi-hw.com/p/ben-wpan/f8cd15e
<qi-bot> [commit] Werner Almesberger: Turn the LED on while in the boot loader. http://qi-hw.com/p/ben-wpan/3c87d9f
<qi-bot> [commit] Werner Almesberger: Implemented AT86RF230 reset and access modes. (Completely untested.) http://qi-hw.com/p/ben-wpan/5447951
<qwebirc47408> i have purchased new nanonote
<qwebirc47408> want oto put it into usb-bbot mode
<qwebirc47408> but when I shorten the two pins then nanonote doesnt bootup
<qwebirc47408> plz help
<kyak> just hold the "U" button during power on
<kyak> no need to shorten if you have a working bootloader
<qwebirc47408> if I am holding U button the it is not booting up
<wolfspraul> qwebirc47408: you don't need to constantly hold it, just before and while you are pressing the POWER-ON button
<wolfspraul> press the power-on (together with 'u') for a good 2-3 seconds
<wolfspraul> then run 'lsusb' on your Linux host machine
<wolfspraul> you should see an ID 0x601a:471a:ns
<wolfspraul> sorry, - you should see an ID 0x601a:4740
<tuxbrain2> qwebirc47408: in USB boot mode you will notice no reaction from nanonote , screen black , you hve to check if is in usb boot by lsusb in host computer and see a new device 0x601a:4740
<wolfspraul> do you see that ID?
<qwebirc47408> let me check
<qwebirc47408> yes i m getting
<qwebirc47408> how can I develop any C application for it and run over nanonote
<wolfspraul> qwebirc47408: that's a great start! :-)
<wolfspraul> if you see that ID, it means your NanoNote is alive, the CPU is running, and waiting for instructions
<wolfspraul> it is not supposed to boot in that mode
<qwebirc47408> ok
<qwebirc47408> what to do next
<wolfspraul> now you can run reflash_ben.sh, although I hate that script :-)
<qwebirc47408> I want to reflash the  nanonote
<qwebirc47408> how shall I run usbboot application
<wolfspraul> you have usbboot installed already?
<wolfspraul> then just run reflash_ben.sh
<qwebirc47408> how to check it
<qwebirc47408> i have installed openwrt-xburst
<wolfspraul> you need to install the xburst-tools package
<wolfspraul> that's the sources, that comes later
<qwebirc47408> yes I have
<wolfspraul> do you have reflash_ben.sh ? download and run
<wolfspraul> I believe we do have some instructions in the wiki for that
<wolfspraul> if you see the 601a:4740 ID all is fine. Now run reflash_ben.sh
<qwebirc47408> I have downloaded reflash_ben and running it
<qwebirc47408> what all will happen with this
<wolfspraul> it will download the 0613 image and reflash the ben
<kyak> weren't all these questions from beginner's guide?...
<bartbes> btw, wasn't there a photo viewer?
<wolfspraul> bartbes: imgv
<bartbes> is it in the default image?
<bartbes> yes, it is
<bartbes> thanks!
<wolfspraul> he, just trying
<bartbes> ah well, my jpeg is too big
<bartbes> (for the memory)
<wolfspraul> we will cleanup the openwrt default app list and testing plan 'really soon', then a lot more should be included and stay included
<bartbes> interestingly enough I have yet to run out of memory while running a game engine, while I run out wanting to view a simple photo
<wolfspraul> I have imgv but if I run it without parameters it just hangs
<wolfspraul> :-)
<wolfspraul> scaling pictures can be very memory consuming, unless the scaling algorithm is specifically written to reduce memory footprint
<wolfspraul> imgv --help or --version should at least say something, oh well...
<bartbes> true
<bartbes> anyway, it was just a test to see if my camera supported SDHC
<bartbes> well, 'my' imgv doesn't hang when I run it (even without parameters)
<bartbes> and about why --help and --version don't help, they just don't exist ;)
<bartbes> I doubt it does any kind of arguments
<kyak> cp: cannot stat `./files/qmake.conf': No such file or directory
<kyak> this is from recent qt
<kyak> actually, i'm tired of things being broken every now and then upstream
<kyak> i should better neve make package/symlinks
<kyak> do they even test before they commit?
<bartbes> kyak: testing is overrated :P
<wolfspraul> mirko: how is imgv supposed to work? in the 08-15 testing image, I try 'imgv some_image.jpg' and it just hangs.
<wolfspraul> ctrl-c will exit
<qwebirc26781> reflashing is taking long time . is it ok ?
<wolfspraul> how long?
<wolfspraul> 20-30 minutes should be ok.
<qwebirc26781> it is already 1 hr gone but stuked at fetching rootfs
<wolfspraul> that's not right
<wolfspraul> oh well
<wolfspraul> wait, maybe it is downloading? what is your internet speed?
<qwebirc26781> 512Kbps
<wolfspraul> could take an hour maybe. not sure. also I don't know how to check the download progress with the script.
<qwebirc26781> how can i develop simple C application for it
<qwebirc26781> and test it
<rafa> wpwrak: hey, after a while, yesterday, the bechnmark gives better values, no a lot more though.. : 65MB/s
<bartbes> yeah, most tests you need to avarage as well
<wolfspraul> zedstar: sorry I haven't gotten to replying to your mail yet. definitely will!
<bartbes> sometime
<bartbes> in about 3 years
<bartbes> or later
<wolfspraul> he
<wolfspraul> I spend 50% of my time adding items to my todo list nowadays. Something is wrong...
<lars_> you should add 'Stop adding items to my todo list' to your todo list ;)
<bartbes> or if you want to cross something off
<bartbes> 'Add something to my todo list'
<wiwitu> hey guys
<wiwitu> quick question: whats the name for a powersupply with 16 pins, I cannot find one on the internet
<lekernel> wtf? there are billions of power supplies with 16 pins
<lekernel> if you're talking about PC power supplies this is the wrong channel
<viric> he left, maybe realising that
<bartbes> he ran out of power ;)
<wpwrak> hmm, if anyone is running a recent kernel under openwrt, it would be interesting to try the memset benchmark there, too. to exclude kernel differences as possible causes.
<wpwrak> the code is here: http://pastebin.ca/1919777
<wpwrak> lekernel: nice analysis, thanks ! so my estimates are basically sane.
<wpwrak> (running the benchmark) just compile, maybe with -O9 to make sure the compiler doesn't do anything funny, run top to make sure that there's nothing that burns cpu, then run the benchmark a few times with time ./a.out
<wpwrak> it just takes a few seconds
<lekernel> try enabling RT priority too (ie context switches disabled)
<lekernel> and write your own memset, in assembler if needed
<wpwrak> lekernel: (rt) naw, i'd rather not do that. might upset the timekeeping.
<lekernel> then use hwclock calls?
<wpwrak> (own memset) i hope to get others interested in doing that, should it be necessary :)
<wpwrak> (hwclock) uh, too complex for this little benchmark
<wpwrak> it's not as if it would suffer high variability anyway
<lekernel> apparently it does :)
<wpwrak> right now, i'm not so much after maximizing memset, but after confirming that openwrt-based memset is slower than jlime-based
<wpwrak> on the same system ? just a few percent
<wpwrak> @#%. why does that silly device not respond to my control messages. almost the same code worked a gazillion times before.
<wpwrak> hates chasing trivial bugs
<wpwrak> oh, lovely. looks like yet another sdcc compiler bug :-(
<viric> what do you need to benchmark?
<viric> I'm not running openwrt, but I run a 2.6.35.1 iirc
<wpwrak> viric: is your system uClibc-based ?
<viric> wpwrak: no
<viric> glibc.
<viric> I can build that program for uclibc maybe.
<viric> (not with glibc)
<wpwrak> well, could be useful to have another data point anyway. what system is it ? debian ?
<viric> wpwrak: It's nixpkgs based
<viric> wpwrak: (glibc 2.11.2, gcc 4.5.1, kernel 2.6.35.1)
<wpwrak> oh, very exotic ;-) another data point would definitely be fun then :)
<viric> is that going to give evident results? or I have to measure in any special way?
<wpwrak> viric: naw, just check with top nothing else burns a lot of cpu time. then run the benchmark a few times with  time ./a.out
<viric> ok
<viric> wpwrak: a dynamic ELF?
<wpwrak> doesn't matter
<wpwrak> just use -O9 to make sure gcc tries to be efficient
<viric> O9?
<wpwrak> gcc -O9
<viric> ok ok
<viric> I thought you had mistyped -O0 :)
<lekernel> -O9 is like -O3 iirc
<lekernel> just like any -Ox with x > 3
<viric> ok
<wpwrak> lekernel: yup. it's idiomatic use for "make it as fast as you can" :-)
<viric> running
<viric> around 4.44s on avg for real/user time
<viric> wpwrak: is that good?
<wpwrak> viric: interesting. that's about 57 MB/s, much faster than openwrt but a bit slower than jlime
<wpwrak> maybe rafa is just overclocking his ben ;)
<mth> the boot loader does the SDRAM initialization, so it can be relevant for memory bandwidth
<mth> although I think all distros use the same boot loader, right?
<viric> hehe
<viric> wpwrak: is that jlime uclibc based?
<wpwrak> mth: oh. the kernel doesn't reset those things ? darn
<viric> I'll tell you what bootloader I use...
<mth> no, the current kernel does not touch them
<nebajoth> jlime is faster than openwrt?
<wpwrak> mth: sigh. one more variable in the equation :-(
<mth> the old gmenu2x version does change the PLL frequency, which also determines the MCLK value
<viric> I'm using uboot 2010.06 with the patches from openwrt-xburst tree 3244d5ef9f93802f9b9b6f4405636424abf6fa83
<wpwrak> (gemnu2x) wow. boldly stumbling where even the kernel doesn't dare to go
<mth> the new gmenu2x uses cpufreq in sysfs to control the clocks, but there is no cpufreq support in the NanoNote kernel yet
<mth> but the old gmenu2x would reprogram the hardware via /dev/mem
<wpwrak> nebajoth: at least for memset, it seems to be
<wpwrak> mth: are you by any chance running an up to date openwrt at the moment ?
<mth> no, I don't even have a NanoNote, only a Dingoo
<wpwrak> ah, pity
<mth> I'd like to see openwrt run on the Dingoo, but we didn't get very far yet
<mth> I did port lars_'s kernel though
<wpwrak> kewl
<nebajoth> what is lars_'s kernel?
<mth> the one in the qi-kernel repository
<zear> mth, rafa's getting my old dingoo soon, so we can hope for jlime port to the dingoo ;)
<mth> nice :)
<mth> rafa: please use the OpenDingux kernel then, it's more up-to-date than booboo's and it's still being maintained
<mth> if you encounter any problems, please ask me
<viric> as in 'what mips processor' the nanonote has... it's mips1?
<mth> also, it is much more like the NanoNote's kernel
<viric> (from the options mips2, mips3, ...)?
<mth> mips32 I think
<mth> or maybe mips32r2?
<viric> ah
<viric> how to know?
<viric> I'll go for mips32r2
<viric> and see
<qi-bot> [commit] Werner Almesberger: Added library for items commonly shared among tools. http://qi-hw.com/p/f32xbase/7501137
<qi-bot> [commit] Werner Almesberger: version.h is no longer generated and it thus only creates confusion if http://qi-hw.com/p/f32xbase/2a58505
<rafa> mth: what?
<rafa> opendingux kernel for what?
<lars_> viric: mips32r1
<viric> in terms of gcc arch, mips32, right?
<lars_> yes
<viric> ok
<rafa> mth: ah.. for dingoo :D
<rafa> mth: yeah.. I still need to learn the whole system you already have
<qi-bot> [commit] Werner Almesberger: Put libraries at end of linker invocation to make it work with local http://qi-hw.com/p/f32xbase/fa7fb48
<qi-bot> [commit] Werner Almesberger: - fw/atspi/Makefile (USB_ID): corrected and updated USB ID extraction http://qi-hw.com/p/ben-wpan/9a6b3fc
<qi-bot> [commit] Werner Almesberger: More config rearranging: USB IDs are now in include/atspi/usb-ids.h, which http://qi-hw.com/p/ben-wpan/537c675
<qi-bot> [commit] Werner Almesberger: Simplified the presentation of build date information and added a http://qi-hw.com/p/ben-wpan/bb4b07f
<qi-bot> [commit] Werner Almesberger: Fix typo and make "make dfu" work again. http://qi-hw.com/p/ben-wpan/bf74a03
<qi-bot> [commit] Werner Almesberger: Introduce library with ATSPI access functions (largely untested) http://qi-hw.com/p/ben-wpan/ac349b0
<wpwrak> ah, been a while since the last push ;-)
<viric> wpwrak: that benchmark I did... all was compiled for mips1
<viric> wpwrak: instead of mips32
<viric> wpwrak: I'll try with uclibc your memset benchmark
<viric> wpwrak: 4.03s in average
<viric> it is gcc 4.5.1 + uclibc 0.9.31 for mips32
<viric> (statically linked test)
<viric> wpwrak: Now I built with glibc for mips32 (the 4.4s measure was for mips1), and in this case I get an average of 3.96
<wpwrak> ah, so now they're the same. 64 MB/s.
<viric> is that the jlime speed?
<viric> I hope with this 'mips32' (I thought I had to use mips1 before) prboom will take less battery :)
<wpwrak> yes, that's roughly the jlime speed. i think rafa said ~68 MB/s. so that's well within tolerances.
<qi-bot> [commit] Juan64Bits: Routing http://qi-hw.com/p/xue/899d599
<wpwrak> hehe ;-)
<wpwrak> ah no. he wrote 65 MB/s. so it's the same.
<wpwrak> what options did you use on gcc ?
<viric> building gcc?
<wpwrak> no, when invoking it
<viric> gcc -static -O9
<wpwrak> ah, nothing special for the cpu then
<viric> well
<viric> the gcc was built with "--with-arch=mips32"
<viric> so it assumes that arch
<viric> at every invocation
<wpwrak> hmm. mine seems to be mips1, too
<wpwrak> the mips gcc should support several mips targets. you can switch them with -march=mips1|mips32|etc. no need to rebuild gcc just for that
<viric> right.
<viric> well, for my case it's not any additional effort
<viric> and this way I don't have to set anything special building every package. I get mips32 everywhere
<wpwrak> one man's excessive effort is another man's laziness ;-)
<viric> :)
<wpwrak> now, let's see how this goes on my ben ...
<wpwrak> i should probably remove gmenu2x if it likes to play with the clocks ...
<viric> I don't have it
<tuxbrain2> I think the newest version should not play with clocks it was removed due flickering screen problems, but I'm not totally sure about this
<viric> do you use any NES emulator in the ben?
<wpwrak> tuxbrain2: yes, but this ben of mine still has the factory installation. i'll save the system upgrade for another day.
<wpwrak> viric: me ? no. so far, i hardly "use" it at all. it suffers considerable abuse on the hardware side, though ;-)
<tuxbrain2> so if you have the old gmenu2x yes remove it to do the performance tests
<viric> wpwrak: ok :)
<wpwrak> after getting rid of gmenu2x, i get ~60 MB/s. too. no difference between mips1 and mips32 here. mips32r2 is a bit faster, though. (~2 MB/s)
<viric> wpwrak: lars_ said the cpu should be mips32, not mips32r2
<viric> maybe it is something in between
<viric> wpwrak: the difference between mips1 and mips32 is at the time of compiling the libc, not the program
<wpwrak> (mips1) ah, okay
<wpwrak> (mips32r2) maybe it turns into a mips32r2 only for benchmarks ;-)
<viric> tuxbrain2: can you paste somewhere your asoundrc configuration?
<tuxbrain2> viric actually using jlime , it can be valid?
<tuxbrain2> also if you can tell me where this file is sopossed to be will be helpfull as well, I using opkg that drain resources as hell and not able do do a #find
<viric> yes
<viric> I only want the soft volume
<viric> tuxbrain2: ~/.asoundrc?
<viric> or /etc/alsa/asoundrc? I'm not sure
<tuxbrain2> I have no found any asoundrc file in jlime---?
<viric> oh.
<viric> and you have softvol?
<viric> Btw, I'm trying to run mpg321, and it does not work fast enough for the ben
<viric> although it uses the same libmad 'madplay' should use.
<qi-bot> [commit] Andres Calderon: some eth-phy to s6 nets has been routed http://qi-hw.com/p/xue/033f361
<qi-bot> [commit] Andres Calderon: some eth-phy to s6 nets has been routed http://qi-hw.com/p/xue/e0d4a59
<qi-bot> [commit] Andres Calderon: some eth-phy to s6 nets has been routed http://qi-hw.com/p/xue/7c3c9a8
<qi-bot> [commit] Andres Calderon: some eth-phy to s6 nets has been routed http://qi-hw.com/p/xue/a56645a
<qi-bot> [commit] Werner Almesberger: Active-high IRQ_RF was routed to active-low interrupt input http://qi-hw.com/p/ben-wpan/1d07933
<qi-bot> [commit] Werner Almesberger: xxx_MODE were used as if they were port bits, not registers. http://qi-hw.com/p/ben-wpan/14c1b4c
<qi-bot> [commit] Werner Almesberger: We can now read the transceiver's registers. http://qi-hw.com/p/ben-wpan/4b20421
<turtlee> hi all.
<wolfspraul> hi
<turtlee> Mr. Spraul! Nice to meet you.
<turtlee> I got my nn on Monday and have been enjoying it.
<wolfspraul> same here - what takes you here?
<wolfspraul> oh nice! well thanks for buying one first of all!
<wolfspraul> you just entered a massive construction site :-)
<turtlee> Hehe. I can see that! But it's well worth it. It takes me back to the fun of discovery I enjoyed as a child in the late 1980s.
<turtlee> I'm here tonight because I've been playing with the startup sequence and I'd like to understand it better.
<wolfspraul> turtlee: "I am a craftsman and I live and work within the belief that fine, durable workmanship combined with good design helps create a better world. I am passionate about quality and have been fortunate to study its expression in wood, metal, leather, and stone."
<wolfspraul> that's you?
<turtlee> Indeed it is.
<wolfspraul> great! we wish we get to those standards one day... it's a very good mission statement.
<wolfspraul> Werner has been doing some 3D scanning work lately, have you seen that?
<turtlee> No, I haven't. Do you have a link?
<nebajoth> mailing list thread about the 3d scans: http://lists.en.qi-hardware.com/pipermail/discussion/2010-July/003231.html
<nebajoth> also welcome turtlee
<nebajoth> your mission statement sounds awesome
<turtlee> Thanks very much. I also like this quote from Anthony Bourdain that a friend sent me the other day:
<turtlee> People will continue to pay for quality. They will be less and less
<turtlee> inclined, however, to pay for bullshit."
<turtlee> woops.
<turtlee> "If there's a new and lasting credo from the Big Shakeout, it's this: People will continue to pay for quality. They will be less and less inclined, however, to pay for bullshit."
<turtlee> Well, close enough.
<wolfspraul> well exchanging these nice words is good, but for the Ben we have to keep our expectations realistic. It's a long way.
<wolfspraul> for example several connectors really suck, sorry about that
<wolfspraul> as a mechanical guy it's painful for me to imagine that you take a closer look one day
<wolfspraul> battery connector for example
<wolfspraul> microSD connector, especially insertion pin
<turtlee> Fair enough, but it's still a pleasure to hold, and that's a start.
<wolfspraul> thanks, yes. it's not a hopeless start.
<wolfspraul> did you see werner's work?
<wolfspraul> (the url)
<turtlee> I did. It's wildly cool. Thanks very much.
<turtlee> So, were there not solid models before the molds were made?
<wolfspraul> we bought the design, and the tooling process was done without any input or oversight from us
<turtlee> Ah, that makes sense.
<wolfspraul> our volumes are too low for our own professional mechanical design right now
<wolfspraul> but now we have work like Werner's so hopefully we get this process all opened up slowly
<wolfspraul> werner is hanging out here in irc, btw, his nick is wpwrak
<turtlee> At least you found a way to produce at your low volumes.
<wolfspraul> yes
<wolfspraul> very hard work, but it's moving
<turtlee> I preordered a Pandora last December. Ultimately gave up.
<turtlee> Cancelled and ordered a BeagleBoard and an nn.
<wolfspraul> yes our project is very different from those, in priorities
<wolfspraul> for me manufacturability comes first
<wpwrak> welcome, turtlee ! you came to the right place :) mechanical is the weakest area of the whole process (and the device has its flaws there, too)
<turtlee> Thanks, Werner. :)
<turtlee> I look at the frustration on the Pandora boards, and I think if they'd started from manufacturability at the outset, they could have arrived at this point with a lot more polish on the software and a lot more enthusiasm, even after the long wait.
<nebajoth> hell yeah
<nebajoth> wolfspraul is a pragmatist
<nebajoth> and it makes all the difference in the world
<wolfspraul> the pandora guys are fighting a massive uphill battle
<nebajoth> just like torvalds is a pragmatist
<wolfspraul> first they use more 'high-tech' than we have in the NanoNote, like the OMAP chip, and Wi-Fi
<turtlee> I've been cruising around playing Flashback (via REmeniscence) and Monuments of Mars (via dosbox) on my nn.
<wolfspraul> then they do some work steps in China (mechanical), but they seem to have zero experience in actual manufacturing, so they learn painful lessons, and slowly.
<wolfspraul> now they are moving more work to the UK, and sooner or later they will realize that costs are going through the roof.
<wolfspraul> so I don't know.
<wolfspraul> I make my little NanoNote.
<wolfspraul> maufacturing under control
<turtlee> And I enjoy your little nanonote.
<wolfspraul> can sell profitably at 99 USD, actually working towards reducing prices
<wolfspraul> I take the beating and laughing over the hardware specs, no problem. Others can wait for their Pandora, position whatever in the queue :-)
<turtlee> Heh, and they're just another layer. Look at the comments at Engadget about Pandora, and it's the same story.
<wolfspraul> people don't like the hw specs anymore?
<wolfspraul> engadget is typically just a hw spec pissing match
<turtlee> Exactly.
<wolfspraul> "hey, my LCM has 40,000 dpi, how about yours?"
<turtlee> So, here's my experience:
<wolfspraul> it's hilarious :-) also engadget has how much percent news that is just announcements? I stopped wondering.
<wolfspraul> of course if you have to compete over numbers eventually you find out the numbers in the announcements are so much higher
<wolfspraul> we should announce a new NanoNote, with specs that beat the iPhone
<wolfspraul> I'm sure engadget would take the 'story' (ahem)
<turtlee> Hah! That'll net you some press, at any rate.
<wolfspraul> yeah, embarassing, isn't it.
<wolfspraul> this will never happen here.
<turtlee> Bravo.
<wolfspraul> I rather build it slowly and through actual strength rather than announcements strength.
<turtlee> You and I are of the same mind.
<wpwrak> wolfspraul: you're too late. there's that video about the "xphone" ...
<turtlee> looks into the youtube
<turtlee> Hah!
<turtlee> I took my foray into app-phones with a Droid, and am nonplussed. I think it's fair to say that I am not the target audience for convergence devices.
<turtlee> Anyway,
<turtlee> I do have some specific tech questions.
<turtlee> (and will be back here to talk shop again. you guys are fantastic.)
<nebajoth> what
<nebajoth> its a trap!
<wolfspraul> wpwrak: hah yes, it's great! thanks for the link didn't see it before
<turtlee> I've already deactivated the gp2x menu
<turtlee> per the new user guide instructions on the wiki.
<nebajoth> real men run debian
<turtlee> nebajoth: Ah! So they do. Do we have a good keymap for debian yet?
<nebajoth> well
<nebajoth> yes
<nebajoth> not integrated into the rootfs yet though :D
<nebajoth> but nothing keeping anybody from downloading it and using loadkeys
<nebajoth> and even making it automatic
<turtlee> Brilliant.
<turtlee> Because that would probably induce answers to my other questions right away.
<nebajoth> that one works nicely
<nebajoth> I further customized that one to make the capslock key give a dash (-)
<nebajoth> which I use all the time since I don't have any graphical environment installed on my NN
<turtlee> And the flashing instructions on pyneo.org are good?
<nebajoth> yeah basically
<nebajoth> it leaves out some important bits
<nebajoth> like the fact that you pretty much NEED swap space to run apt-get
<nebajoth> at least until I figure out where the hell compcache went in 2.6.36
<turtlee> But I can put that on the onboard nand, right? I've got an 8gig microsd. Not exactly hurting for space.
<nebajoth> right
<nebajoth> I do it the other way around
<nebajoth> OS on the nand, swap on a 1G microsd
<nebajoth> but what you describe would be fine
<nebajoth> possibly even better
<wolfspraul> turtlee: large parts of the Ben NanoNote kernel will be showing up in the 2.6.36 mainline kernel!
<nebajoth> yeah that's my headache now
<wolfspraul> that's really excellent and I hope it will make the job of people like nebajoth working on Debian easier...
<nebajoth> I want to compile 2.6.36
<nebajoth> but I also want to enable compressed ram
<nebajoth> and there seem to have been some serious changes in the way compressed ram is dealt with in 2.6.36
<wolfspraul> maybe it will make your life easier over time :-)
<nebajoth> and I'm trying to wrap my head around it
<nebajoth> haha
<nebajoth> yes
<nebajoth> I'm sure 2.6.37 will be AWESOME
<turtlee> Wow, with so many distros running around, it's easy to forget that there's still a central kernel dev effort.
<nebajoth> somebody doesn't read his lkml
<nebajoth> (:P)
<wolfspraul> actually I am also working on getting xburst-tools into Debian
<wolfspraul> puh, hard
<nebajoth> epic
<wolfspraul> maybe soon we'll be there
<nebajoth> we're gonna need zramconfig in there too
<nebajoth> I'll attempt it
<nebajoth> I'm not adding to your todos
<nebajoth> just saying
<nebajoth> well hell
<wolfspraul> nebajoth: zramconfig in where?
<nebajoth> it should make it easier that its in ubuntu
<nebajoth> in debian
<wolfspraul> I first want to get it into Debian, then improve the code inside (usbboot & xbboot utilities).
<nebajoth> its the userspace configuration utility for compressed ram
<nebajoth> I'm going to have to compile it from source
<nebajoth> if I ever get past the 2.6.36 kernel compile
<nebajoth> which is looking increasingly headachey
<turtlee> i'm the opposite of an expert on software engineering, but shouldn't a kernel compile be the most brain-dead-simple compile in the world?
<wpwrak> simpler than "hello world" ? :)
<turtlee> Well,
<turtlee> i mean,
<turtlee> Don't you need a kernel before you can have "hello world"?
<nebajoth> haha
<turtlee> (Maybe I just need a kernel before I can have "hello world".)
<nebajoth> its not hard to actually compile
<nebajoth> what I'm finding difficult
<nebajoth> is determining what happened to the actual architecture of the component I need
<nebajoth> they renamed it, for one
<nebajoth> all the CONFIG_X options seem gone
<nebajoth> and there's zero documentation outside of the git changelogs
<nebajoth> so I'm looking through those, trying to figure out whether the CONFIG_X settings got moved, removed, or what
<turtlee> That's...odd. o_O
<nebajoth> yeah
<nebajoth> its probably really simple
<nebajoth> and I just don't understand what's going on
<nebajoth> I think it might just not need configs anymore
<nebajoth> and they're gone
<qwebirc91025> hi
<turtlee> So, swap was invented to make up for inadequate physical RAM,