DocScrutinizer05 changed the topic of #qi-hardware to: 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 and http://irclog.whitequark.org/qi-hardware
emeb has left #qi-hardware [#qi-hardware]
xiangfu has quit [Remote host closed the connection]
wolfspraul has joined #qi-hardware
wej has joined #qi-hardware
zrafa has quit [Ping timeout: 252 seconds]
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #qi-hardware
zrafa has joined #qi-hardware
wolfspraul has quit [Remote host closed the connection]
wolfspraul has joined #qi-hardware
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #qi-hardware
rz2k has quit []
pcercuei has quit [Quit: brb]
pcercuei has joined #qi-hardware
freemor has left #qi-hardware [#qi-hardware]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
viric has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
qwebirc71215 has joined #qi-hardware
qwebirc71215 has quit [Client Quit]
MistahDarcy has quit [Read error: Connection reset by peer]
MistahDarcy has joined #qi-hardware
MistahDarcy has quit [Ping timeout: 272 seconds]
jluis has joined #qi-hardware
<viric> kyak: whitequark: когда и где? Мне всё равно
wolfspraul has quit [Quit: leaving]
jekhor has joined #qi-hardware
porchaso0 has joined #qi-hardware
pcercuei has quit [Quit: dodo]
porchao has quit [Ping timeout: 256 seconds]
coyo has quit [Remote host closed the connection]
coyo has joined #qi-hardware
coyo has joined #qi-hardware
lekernel has joined #qi-hardware
kuribas has joined #qi-hardware
jekhor has quit [Ping timeout: 272 seconds]
bitHipy has quit [Ping timeout: 245 seconds]
bitHipy has joined #qi-hardware
Calyp has joined #qi-hardware
panda|x201 has joined #qi-hardware
jekhor has joined #qi-hardware
wej has quit [Ping timeout: 248 seconds]
wej has joined #qi-hardware
unclouded has joined #qi-hardware
freemor has joined #qi-hardware
mth has quit [Ping timeout: 272 seconds]
unclouded has quit [Ping timeout: 272 seconds]
wolfspraul has joined #qi-hardware
wolfspraul has quit [Client Quit]
wolfspraul has joined #qi-hardware
mth has joined #qi-hardware
jekhor has quit [Ping timeout: 260 seconds]
<viric> whitequark:
<viric> oops
jekhor has joined #qi-hardware
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
kuribas has joined #qi-hardware
<larsc> what are you guys plotting?
<viric> a meeting :)
<larsc> ah ok, it sound all mysterious "tomorrow night?" "Da!" "when and where?" ;)
<viric> :)
<viric> isn't this a common way to meet? :)
<larsc> I guess the russian made it more mysterious
<viric> imagine if it was german.
<viric> far more misterious ;)
<larsc> hehe
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
erikkugel has joined #qi-hardware
pcercuei has joined #qi-hardware
cod3r has joined #qi-hardware
lekernel has quit [Quit: Leaving]
lekernel has joined #qi-hardware
dandon has quit [Ping timeout: 245 seconds]
dandon has joined #qi-hardware
cod3r has quit [Ping timeout: 246 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #qi-hardware
wej has quit [Ping timeout: 245 seconds]
jluis has quit [Ping timeout: 245 seconds]
wej has joined #qi-hardware
cod3r has joined #qi-hardware
dandon has quit [Ping timeout: 248 seconds]
porchaso0 has quit [Ping timeout: 258 seconds]
dandon has joined #qi-hardware
wej has quit [Ping timeout: 264 seconds]
wej has joined #qi-hardware
emeb has joined #qi-hardware
<whitequark> larsc: hehehe
dandon_ has joined #qi-hardware
dandon has quit [Ping timeout: 255 seconds]
dandon_ is now known as dandon
mog has quit [Excess Flood]
mog has joined #qi-hardware
mog has quit [Changing host]
mog has joined #qi-hardware
dandon has quit [Ping timeout: 252 seconds]
dandon has joined #qi-hardware
lekernel has quit [Read error: Connection reset by peer]
<kyak> хехе
kuribas has joined #qi-hardware
woakas has quit [Ping timeout: 258 seconds]
woakas has joined #qi-hardware
pcercuei has quit [Quit: brb]
pcercuei has joined #qi-hardware
deceivorz has joined #qi-hardware
wej has quit [Ping timeout: 245 seconds]
wej has joined #qi-hardware
dandon has quit [Ping timeout: 248 seconds]
<apelete> hi
dandon has joined #qi-hardware
<apelete> I just cloned git://projects.qi-hardware.com/qi-kernel.git, can someone tell me which branch of that repo is actually used to build the nanonote kernel ?
<apelete> wiki page http://en.qi-hardware.com/wiki/Ben_NanoNote/Kernel says jz-3.3, but isn't that old/outdated ?
<viric> Success!
<larsc> apelete: jz-3.6 is the latest
<larsc> viric: did you find them?
dandon has quit [Ping timeout: 260 seconds]
<viric> :) yes
<larsc> say hello from me
<viric> I mentioned you
<viric> someone mentioned AD :)
<viric> (I only had good words about you)
<apelete> larsc: thanks. so jz-3.6 includes all the qi-hardware kernel patches for the NN ?
<viric> larsc: in fact it was whitequark who got into internet after 5 seconds of entering the bar
<wpwrak> larsc: oh, you mentioned your 3.9 tree. it that on qi-kernel ? i saw that you create a branch but there doesn't seem to be a lot in there.
<larsc> apelete: yes
<wpwrak> viric: was the vodka not to his liking ?
<larsc> wpwrak: 3.9-rc8 is on qi-kernel
<viric> in 6 seconds he was already ringing me through SIP, through his VPN n who knows what land, through the bar free wifi.
<larsc> wpwrak: 3.9 is on my laptop
<wpwrak> ah ;-)
dandon has joined #qi-hardware
<larsc> but I can push that pu
<larsc> out
<larsc> without all the dma and clock changes
<larsc> for now
<wpwrak> i'm curious about your board-qi_lb60.c. i think that's the best place to put what's left from atben.c (mainly code to connect the drivers, plus a small reset function).
<larsc> probably
<apelete> are you guys still working on the nanonote kernel by the way ?
<pcercuei> of course
<wpwrak> apelete: that's just what we're talking about :)
<apelete> I'm trying to create a BSP for the NN in the openembedded build system
<apelete> I think I will start with your work, eg. build a qi-hardware kernel and maybe uboot to create a mninimal bootable image for the NN with openembedded
<apelete> my goal is to make the BSP available in oe for those who prefer to use that build sytem instead of openwrt
<apelete> what do you think about it ?
<larsc> go for it
<larsc> wpwrak: pushed the branch
<apelete> larsc: ok, will try to build jz-3.6, and then go from there and try to integrate it inside oe
<apelete> will let you know how it goes
<larsc> apelete: you could actually try jz-3.9 now that it is out on the wild
<apelete> larsc: ah, that's great, will try that instead then
<wpwrak> larsc: thanks !
<wpwrak> apelete: btw, there's also OE-based jlime. i think it hasn't been updated for ages, but there may still be things in there that are useful for you. not sure to what extent they pushed their changes up to OE.
<wpwrak> (board-qi_lb60.c) oh, refreshingly similar ;)
<wpwrak> you;re missing xiangfu's "qi_lb60: NAND: add data partition"
<wpwrak> before that, ubi was VERY unhappy with what it saw
<larsc> that kernel boots fine on my board
<apelete> wpwrak: I've been working on oe-based jlime for the past months, fixed a couple of things in the distro and modified it to build a ubi rootfs by default: http://git.openembedded.org/openembedded/commit/?h=2011.03-maintenance&id=91052aa8adea176d1ecb46e6b458a576938e0e8e
<apelete> wpwrak: now I'm trying to update the BSP, because jlime is still using kernel 2.6.36
<wpwrak> apelete: oh, great !
<wpwrak> larsc: hmm, maybe you have a special OWRT installation then. i think it normally doesn't touch the data partition, so whatever is there (if there's anything) will upset UBI
<larsc> I use an image downloaded from downloads.qi-hardware
<apelete> wpwrak: the qi-hardware kernel seems to be a sensible choice to create an up-to-date BSP, and using your work should help minimize the effort
<apelete> if I succeed in creating the BSP, maybe I could help you with upstreaming the patches if you don't mind
<larsc> the oe patches?
<wpwrak> larsc: i don't know how UBI is structured internally, but it may just consider the whole partition as containing potential data. in this case, what you get when putting a small image on a larger partition would depend on the history of that partition
<apelete> larsc: you said on the ml that some help was needed to write glue code in the kernel: http://lists.en.qi-hardware.com/pipermail/discussion/2013-April/010117.html
<larsc> wpwrak: feel free to apply the patch, I'll see if anything breaks on my side
<wpwrak> apelete: (use the qi-hw kernel) yes, definitely. i don't think there are any "parallel" kernels that are maintained
<larsc> apelete: for the usb gadget driver. So the situation is that we have a usb gadget driver which is in a horrible shape
<wpwrak> larsc: i use it in my kernel. first, i tried to run without it, and all hell broke loose.
<pcercuei> apelete, interested in a tiny bootloader for jz4740 that boots straight to UBI?
<larsc> apelete: and there already is a upstream driver for this ip core which we'd prefer to use, but we need to write the glue code for the jz4740 SoC
<wpwrak> larsc: this sort of things: http://pastebin.de/34124
<apelete> larsc: yes, that's what I understood. maybe we could talk about it later, when I get the BSP working in OE, but I'll gladly help with the coding if necessary
<wpwrak> maybe someone from the OWRT crowd would know whether the root/data partition split should be considered mandatory or whether just a large root partition should work too ?
* wpwrak waves in the general direction of mth and kyak :)
<apelete> pcercuei: you mean a bootloader that replaces uboot ?
<pcercuei> yes
<mth> wpwrak: I know very little about OWRT; we're using buildroot instead
<mth> and we've got a very strict split between root and data, since our rootfs is read-only (squashfs)
<larsc> wpwrak: I think I erased my whole nand before flashing the image, and I think UBI treats erased pages as free spaces, I guess that's why it works
<apelete> pcercuei: are you running that on GCW Zero game console ?
<wpwrak> mth: ah, i see, sorry. hmm, i why did i think you were on OWRT ?
<mth> we were considering it at some point, but decided it was easier to support a read-only rootfs instead
<wpwrak> pcercuei: ubi.c is impressively small. but you still need some special partition for the kernel, it seems. pity. (i.e., you can't load, say, a file from the rootfs)
<wpwrak> ah, that must be it
<pcercuei> apelete: yes
<wpwrak> larsc: yes, i was thinking of something along these lines (erased blocks == free)
<pcercuei> wpwrak, the bigger the kernel partition is, the longer it takes to boot
<larsc> we don't store the kernel in an ubi parition on the nanonote
<apelete> pcercuei: I'm impressed :)
<pcercuei> hehe why?
<apelete> larsc: config file seems to be missing missing in jz-3.9, where can I get it ? (or should I make my own ?)
<wpwrak> larsc: well, we have a non-UBI partition. same concept, different number of layers :)
<apelete> pcercuei: I have a strong interested in the kernel and bootloader(s) (low level programming stuff), so I think it's impressive to actually write a bootloader, however tiny it might be :)
<pcercuei> well the point was to make it tiny
<pcercuei> the jz processors only load the first 8kB of data into RAM
<pcercuei> so u-boot has to be cut in half
<wpwrak> piranha instead of whale (u-boot)
<pcercuei> one part that initializes the SD/NAND, one part that initializes the rest
<pcercuei> ubiboot is only ~6k with all the features compiled in (serial, MMC+FAT, NAND+UBI)
<larsc> apelete: it should be in arch/mips/config/qi_lb60_defconfig
<larsc> wpwrak: the uImage contains the size in the header. So the loader first reads the header then the remaining bytes, but only as many as it needs, so it doesn't matter how large the partition is
<apelete> larsc: ah, didn't look there, thanks.
<larsc> apelete: make qi_lb60_defconfig
<wpwrak> larsc: was that for pcercuei ?
<larsc> no for you
<kuribas> Is it possible to read the nand flash from a running system?
<kuribas> For example write it to an SD card?
<apelete> larsc: is it possible to 'make uImage' ? or should I 'make vmlinux.bin' and then convert to uImage by using mkimage ?
<wpwrak> larsc: now i'm confused :)
<larsc> apelete: the later
<larsc> wpwrak: doesn't matter ;)
<larsc> kuribas: yes
<wpwrak> apelete: i have a few scripts you may find useful in http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/bin
<wpwrak> apelete: mknnk does "make" for the nanonote kernel (for any make target). nnui does the whole process, including mkimage. fk transfers and flashes the kernel.
<wpwrak> apelete: nnui and fk don't consider modules, so you'd have to "mknnk modules" and scp them separately
<wpwrak> apelete: also, fk falls back to usb boot using idbg if it can't scp. since you probably don't have an idbg, that won't work for you.
<wpwrak> apelete: also, before you can scp, you need to set up usb networking to the ben. the script "ben" would do that. there's a similar one for jlime, called "jlime".
<kuribas> larsc: Or I just leave the kernel that it has, it's maybe not worth the effort if it is a discontinued device.
<apelete> wpwrak: wow, that's great. thanks !
<larsc> kuribas: well your choice. If you are interested in this sort of thing it's an fun exercise
<wpwrak> larsc: hmm, having second thoughts about a flurry of #ifdefs in board-qi_lb60.c. maybe i should just put the atben driver into arch/mips/jz4740 as a subordinate config option for the ben. alas, we don't have any precedent for multi-file board definitions in MIPS. do you think an arch/mips/jz4740/atben-qi_lb60.c would receive a friendly reception ?
<wpwrak> perhaps we need an ecosystem-*/ instead of board-*.c ;-)
<larsc> wpwrak: my plan is to switch jz4740 over to devicetree
<larsc> then you can put whatever you want your dt
<wpwrak> phew. getting complex :)
jekhor has quit [Ping timeout: 240 seconds]
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
erikkugel has quit [Quit: Leaving.]
<larsc> getting simple
<wpwrak> devtree is the origin of several drivers having platform resources and CONFIG_OF in parallel, no ?
<larsc> probably
<apelete> but when I point CROSS_COMPILE to mipsel-openwrt-linux/bin/ directory I get the error "mipsel-openwrt-linux/bin/gcc: cannot execute binary file "
<apelete> what am I missing here ?
<larsc> not sure, might be 32bit vs 64bit
<apelete> larsc: hmm, didn't think about that, but I'm building on a 32bit debian host (it shouldn't be a problem)
<larsc> what does file mipsel-openwrt-linux/bin/gcc say?
<larsc> what does `file mipsel-openwrt-linux/bin/gcc` say?
<apelete> mipsel-openwrt-linux/bin/gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x8258e7968a8994415f7a33655ca2e340edfdcdef, not stripped
<apelete> larsc: so you're right, can't run on my 32bit host
<apelete> I also have a 64bit host though, will try to build the kernel there
<apelete> larsc: thanks for helping
rz2k has joined #qi-hardware
<wpwrak> checking ... still have two 32 bit hosts in regular operation
rz2k has quit [Read error: Connection reset by peer]
<wpwrak> well, two 32 bit x86 hosts
rz2k has joined #qi-hardware
rz2k has quit [Read error: Connection reset by peer]
rz2k has joined #qi-hardware
<larsc> haven't used one in 5 years or so
<larsc> but I have a couple of 32bit VMs
<apelete> gcc: error trying to exec 'cc1': execvp: No such file or directory
<apelete> maybe I should get the full SDK, not just the toolchain
<wpwrak> apelete: you could try to run the openwrt build process. that also generates a toolchain.
<wpwrak> ldd /where/ever/mips-*-cc1 would tell you if there are any problems with shlibs
jekhor has joined #qi-hardware
<wpwrak> after the architecture, that's usually the next stumbling block. i think the pre-compiled toolchain is for some version of ubuntu. may work on debian.
<kyak> the toolchain is for 64 bit hosts -\
<kyak> xiangfu used to build the 32 bit as well, but not for the latest release
<kyak> so yeah, just build your own
<apelete> ok
<kyak> wpwrak: the 0020-qi_lb60-NAND-add-data-partition.patch is needed, since we changed the default partition layout
<kyak> i'm not sure why it works without this patch for larsc...
<wpwrak> yeah, when i tried without it, i received plenty of fire and brimstone :)
<kyak> same for me
<kyak> btw, the naming of toolchain tarball does not suggest that it is for 64 bit hosts. I reported it and even submitted a patch: https://dev.openwrt.org/ticket/11264, more than a year ago
<kyak> a poke to openwrt.
mog has quit [Ping timeout: 256 seconds]
<wpwrak> yeah, the name is somewhat nasty. perhaps it should also make the "linux" a bit more detailed
<wpwrak> well, specific
<wpwrak> i.e., Debian or Ubuntu
coyo has quit [Ping timeout: 245 seconds]
<apelete> got the kernel compilation finally running (by making a few symbolic links in the downloaded toolchain archive, to put all needed executables in a single directory)
<wpwrak> victory is near ;-)
<apelete> will test the result on target tomorrow
<apelete> thanks everyone for helping, time to get some sleep :)
<apelete> good night
<apelete> (will let you know how it went)
<qi-bot> [commit] Werner Almesberger: atben/misc/atben-spi-performance.txt: SPI performance comparison (master) http://qi-hw.com/p/ben-wpan/ff9c7a8
wolfspraul has quit [Ping timeout: 256 seconds]
rz2k has quit []
baba has joined #qi-hardware
cod3r has quit [Ping timeout: 245 seconds]
wej has quit [Ping timeout: 264 seconds]
<qi-bot> [commit] Werner Almesberger: atben-spi-performance.txt: clean up and describe role of referenced code (master) http://qi-hw.com/p/ben-wpan/ec6c09d
wej has joined #qi-hardware
deceivorz has quit []
xiangfu has joined #qi-hardware
jekhor has quit [Ping timeout: 260 seconds]
baba has quit [Quit: WeeChat 0.4.0]