<rjeffries>
wpwrak what are specs for ribon cable that will work wrll with UBB? Part number, source? if I recall correctly the bets option is a cable with 10 wires
<rjeffries>
then one slits it to the correct width and number of wires
<kyak>
seems that it is linked against some libs that are absent from your system
<tuxbrain_away>
I guess those marked as not found? isn't it?
<kyak>
yes, and the addess seems kind of strange
<kyak>
0x00000000
<tuxbrain_away>
well then maybe use the OE toolchain to build has not been such good idea :(
<kyak>
you should build statically if you use non-compatible toolchain, but then this is a bad idea anyway
<Jay7>
kyak: I'll try to build .37 today with OE
<wpwrak>
tuxbrain_away: seems that you mixed up the toolchains from openwrt and jlime. or maybe even the binaries (trying to run jlime build on openwrt or vice versa)
<wpwrak>
tuxbrain_away: if building for openwrt, make sure you didn't run jlime's environment-setup
<wpwrak>
tuxbrain_away: also, if you haven't done so, rm -rf the avrdude tree first
<xiangfu>
tuxbrain_away: make IGNORE_ERRORS=m
<tuxbrain_away>
thanks :)
<tuxbrain_away>
wpwrak: no I don't run
<tuxbrain_away>
jlime's environment-setup but using the OE toolchain but whatever is a bad idea
<tuxbrain_away>
xianfu: then this must be added in the build image wiki page isn't it? if you are ok with this I will add
<kyak>
Jay7: ok
<kyak>
xiangfu: do we need to do something special to run the kernel from openwrt-trunk?
<kyak>
tuxbrain_away: as a temporary measure, maybe this would help you: https://dev.openwrt.org/ticket/8813. You have to adapt the patch for yourself
<kyak>
tuxbrain_away: xiangfu was going to merge the latest backfire into our branch soon, so you might as well wait for that
<tuxbrain_away>
I prefer wait, I have broken too much building systems those days
<larsc>
kyak: shouldn't matter which one you use
<larsc>
kyak: the one from the qi-tree doesn't have the openwrt logo
<larsc>
but that should be all of the differences
<kyak>
larsc: ok then. i tried both, seems there is 2.6.37.1 in openwrt-trunk and 2.6.37 in qi-kernel. But, unfortunately, i have problems booting both -\
<kyak>
by adjusting CONFIG_CMDLINE, i can make it boot to "Starting kernel..."
<kyak>
btw, there is no CONFIG_CMDLINE is config-2.6.37 in openwrt-trunk...
<kyak>
is/in
<kyak>
another thing i noticed is that there is CONFIG_CMDLINE_BOOL now in 2.6.37
<larsc>
hm, that seems rather strange
<kyak>
without it, CONFIG_CMDLINE won't work
<larsc>
i build one from openwrt-trunk when i did the ubi speed-up patches and it worked fine
<kyak>
i put the one from openwrt-trunk in /boot/uImage (rootfs) and boot by pressing the F4
<kyak>
maybe it would work different if i flash it in kernel partition
<kyak>
the uImage from 2.6.32.27 boots well from /boot/uImage without any adjustments
<kyak>
so i was hoping that 2.6.37 will, too
<kyak>
i trying to diff the .config's from 2.6.32.27 and 2.6.37, but it seems futile
<zrafa>
tuxbrain_away: you got that with jlime?
<zrafa>
tuxbrain_away: I mean..the problem .. you can not run it with jlime?
<zrafa>
tuxbrain_away: the problem seems classic :)
<zrafa>
between systems and differents libraries
<zrafa>
tuxbrain_away: so you should get the same if you build with any building system and you try to run the binary on systems with the same arch but different OS
<zrafa>
tuxbrain_away: ah.. wpwrak already said you :)
<kyak>
larsc: i don't understand how you managed to boot the kernel from openwrt-trunk. It fails to find the root without CMDLINE
<kyak>
larsc: hmmmm.. however, the same uImage boot fine from SD card!
<kyak>
i guess it could also work from the kernel partition..
<larsc>
kyak: uboot passes the correct cmdline
<kyak>
larsc: xiangfu: then i'm confused. Two questions: why do we need cmdline in 2.6.32, if it is handled by uboot? And why does uboot work correctly for 2.6.32 (when pressing F4) and doesn't work for 2.6.37 (when pressing F4)?
<xiangfu>
kyak: command can configure kernel mem, console, where is the rootfs. also like g_ether.host ...
<xiangfu>
s/command/cmdline
<wpwrak>
kyak: you know  cat /proc/cmdline  ?
<wpwrak>
kyak: for kexec, you basically have to make sure you're passing the same information
<kyak>
i'm not even talking about kexec now
<xiangfu>
kyak: have you change the nand partition configure in 2.6.37?
<xiangfu>
kyak: by default it's 256M
<kyak>
i'm saying that the 2.6.37 built by default from openwrt-trunk won't bott from /boot/uImage
<xiangfu>
kyak: the nand partition is hard code inside kernel.
<kyak>
it would boot from SD
<wpwrak>
(funny that we need mem=32M. we should auto-detect this. reminds me of the psion s5 where the memory was even scattered in non-contiguous blocks of I think 0.5 MB ;-)
<kyak>
xiangfu: i haven't changed anything
<xiangfu>
kyak: then the nand partition is not correct.
<xiangfu>
kyak: kernel will got error when try to mount nand rootfs partition
<kyak>
xMff: btw, kexec is not working in 2.6.37.1 :)
<kyak>
just checked it
<Jay7>
kyak: :(
<kyak>
Jay7: yep, not very nice.. hope you will have more luck
<wpwrak>
curses DRI
<Jay7>
kyak: not sure..
<Jay7>
larsc: may be you will try to play with kexec? ;)
<kyak>
Jay7: were you able to try kexec with 2.6.37?
<Jay7>
I need to build some image to try
<Jay7>
jlime is unbuildable at this moment
<Jay7>
may be I'll reuse linux-kexecboot kernel to build some other distro (e.g. minimal)
<kyak>
you could also try with openwrt
<Jay7>
I have not touched it before :)
<kyak>
everyone has his first time :)
<Jay7>
yeah :)
<Jay7>
good point to place into CV anyway :)
<Jay7>
but I'm a bit tired after that kexecboot features implementation race :)
<kyak>
kexecboot is a nice piece of software. But it's useless without kexec -\
<Jay7>
sure :(
<kyak>
working kexec
<Jay7>
I have no enough skills to debug/fix it
<Jay7>
this is task for kernel and kexec-tools guys
<Jay7>
btw, wrt compressed uImage
<kyak>
and for those knowing mips well. I asumen it is very architecture-specific
<Jay7>
iirc, someone was tested uncompressed kernel + compressed uImage vs compressed kernel + uncompressed uImage
<Jay7>
and second win
<Jay7>
but that was on Zauruses iirc
<kyak>
kexec-tools on mips specifically list only "elf-mips" as supported images
<Jay7>
well.. that may be not a problem because kernel is laying on FS
<kyak>
i found that both vmlinux and vmlinux.elf can be loaded successfully (but not ecexuted)
<Jay7>
about execution
<kyak>
uImage can't be loaded -\
<Jay7>
your idea about wrong entry point may be rigth
<Jay7>
but anyway we need some guru :)
<kyak>
yeah
<kyak>
we could also moan in kexec-tools and kernel mailings lists :)
<kyak>
but it's enough of this in google...
<kyak>
without apparant results
<kyak>
off
<tuxbrain>
I think something is wrong on hardware of my NN, doesn't charge the battery (nor on or off) and it can't boot when usb is plugged , it gets stuck on kernel message of g_ether.
<tuxbrain>
I have tried with various batts (even OM ones) to discard is matter of old battery. Any one has experience same problem?
<tuxbrain>
In my case is a minor issue due I'm plenty of replacements here , but I would like to know if is the first case on that .
<Jay7>
tuxbrain: did you tried with other kernel? :)
<Jay7>
some Zaurus models can't bood current kernel with power plugged in
<Jay7>
something is wrong around his power management
<tuxbrain>
Jay7: I have test on jlime kernel and lastest release kernel
<tuxbrain>
same behabiour
<tuxbrain>
jlime beta4 and Blizzar lastest build
<Jay7>
seems HW then :(
<tuxbrain>
the lack of charge even off also points to that.
<wpwrak>
tuxbrain: i may have some problems with charging, too, but haven't examined that in detail. no hangs at g_ether, though
<tuxbrain>
avrdude working on openwrt machine  (at least it trows the help message )
<dvdk>
tuxbrain: saw your video programming an arduino via the Nanonote.
<dvdk>
tuxbrain: you programmed via UBB?  Or some more special adaptor board?
<wpwrak>
tuxbrain: congratulations ! now, you just have to sleep two more nights before you can actually try it :)
<dvdk>
just wondering, since I thought arduine were serial (as in uart) boot loader only.
<tuxbrain>
(re)finishing building avr toolchain binutils and gcc finished but avr-libc , needs x86-avr cross toolchain due oviously can execute mips-avr one
<tuxbrain>
dvdk using NN serial port
<dvdk>
ah, ok that explains it.  what a pitty, then I can't even use the UBBs for that trick :)
<tuxbrain>
dvdk but you can program and comunicate with SPI also directly on chip
<tuxbrain>
yes we will!
<dvdk>
ok, the spi option didn't show up last time i googled and looked for datasheets.  guess that would be the way to go.
<dvdk>
does arduine have the pins (and bootloader) for that?  or are we talking about 'naked' avr chips?
<tuxbrain>
dvdk btw I think to create an ardunote project triying to simplify at maximum Arduino Nanonote relations
<dvdk>
ok, wpwrak, that's neat.
<wpwrak>
dvdk: ubb just gives you access to the pins but doesn't "do" anything. so the two are structurally equivalent. only difference is that one has a led and that i've reshuffled the pins a little
<dvdk>
wpwrak: know that.  just 6 gpios.
<dvdk>
the difference is: I'll have a UBB, but I won't have an 8:10 UART :)
<dvdk>
yeah, i'll put avrdude packaging on my todo list.  it will be nice to show people that Arduino hacking works out-of-the-box.
<wpwrak>
dvdk: you'll probably end up with yet another pin mapping. i don't know what the arduino's connectors look like and what will be a convenient assignment. but all you need is one of those mappings, and avrdude will talk - via the common nanonote driver - to your device
<dvdk>
wpwrak: ok.
<dvdk>
is looking at the bit-banging code
<wpwrak>
dvdk: there are lots of such assignments in avrdude.conf. it works the same for (pc) serial port and parallel port adapters. and there's a gazillion of these ;-)
<dvdk>
yeah, figured that.
<dvdk>
i really think we should get that stuff into the NN firmware image.
<dvdk>
nobody likes to (cross-)compile for nanonote.
<dvdk>
me neither :)
<wpwrak>
(avrdude packaging) great, thanks ! there's still some work i need to do on the avrdude side for devices that need an external clock (the uart will become one of these), but it's already usable for the more common devices that don't need such a thing
<wpwrak>
oh, i like cross-compiling very much ;-)
<wpwrak>
that is, while it works, which is does quite well so far :)
<dvdk>
going to reference git from the openwrt package, so it'll just be one line to change if you update.
<wpwrak>
s/is/it/
<dvdk>
yeah, the most important stuff is the Jz47xx GPIO support from userspace and that's already there.  nice.
<dvdk>
ok, need to sleep.
<dvdk>
good night.
<wpwrak>
when the distributions upgrade to the .36 kernel, then i can also resume work on libbb, which would provide an abstraction layer that could also be used in avrdude
<wpwrak>
(.36 or later)
<dvdk>
wpwrak: even cooler.  kernel driver?
<wpwrak>
for now just user space. but one that takes care of moving the mmc driver out of the way.
<dvdk>
but really need to sleep now
<wpwrak>
kernel is ffs ;-)
<dvdk>
nice.  thought about using UIO?
<wpwrak>
(we'll need the kernel for interrupts)
<dvdk>
-> uio?
<dvdk>
can do irq
<dvdk>
lets continue tomorrow
<dvdk>
cheers
<wpwrak>
is uio something that's in mainline ?
<wpwrak>
oh, it is. nice :)
<wpwrak>
i thought these things would get shut down for political reasons forever ;-)
<lekernel>
followed by that GPL debate... but the linux kernel management seems surprisingly free of such trolls
<wpwrak>
well, the whole concept of user space i/o has only been on hold for something like a 1.5 decades due to gpl circumvention concerns ;-)
<wpwrak>
that's why i was a bit surprised that it had finally made it :)
<wpwrak>
lekernel: ... and with UIO_SERCOS3 and UIO_NETX we already seem to have two fine examples of closed source user spaces
<lekernel>
NVidia already makes proprietary Linux drivers (let alone the proprietary algorithms in the chips), and it doesn't make such a fuss
<Fusin>
wb /me ;)
<wpwrak>
lekernel: well, everbody hates nvidia and would hate to see more of this even more
<lekernel>
there's this funny "nouveau" project spending years on scratching the surface, but that's it
<wpwrak>
lekernel: nouveau is my saviour. they provide exactly what i need.
<lekernel>
and opengraphics which is a massive technical failure
<lekernel>
last time I tried it (it's only one or two months ago), nouveau was very slow and did not support 3D
<wpwrak>
lekernel: yeah, opengraphics is a disaster
<wpwrak>
lekernel: i don't care much about 3d. i want screen real estate. and i figure it's more likely to work if i have two different cards in my pc than two with the same driver. thus i have one nvidia and one ati.
<wpwrak>
lekernel: alas, no intel on-board video in that generation of pc. maybe in the next ...
<lekernel>
so, I'm using the proprietary driver which works just fine, especially that, contrary to Debian, Fedora packages it, which does not waste my time with stupid system administration and kernel header mismatches problems
<Jay7>
VIA/S3 ;)
<Jay7>
but it is hard to get
<wpwrak>
lekernel: well, despite your nick, you're not doing kernel development on your workstation :)
<wpwrak>
Jay7: phew. yeah, that would be another challenge. i heard that there are also some nice multiheads from matrox. but i'd rather limit the complexity of my sourcing ...
<lekernel>
btw, for your 2D use, it wouldn't be too hard to pull off a free GPU
<lekernel>
but I'm not sure if it would make sense economically to do so
<lekernel>
wouldn't be too hard, I mean hardware-wise. getting the X dinosaur to dance is something else.
<wpwrak>
lekernel: yeah, and some niche design would be even more expensive to get in argentina. so i'd have to stock spares and such.
<wpwrak>
(x dinosaur) kdrive ;-)
<lekernel>
btw, how usable is kdrive?
<lekernel>
can it work with the proprietary nvidia driver including 3D?
<lekernel>
or maybe at least decent 2D acceleration
<lekernel>
I don't need 3D so often
<wpwrak>
i think it's strictly 2D. no idea how it relates to nvidia. i know it as a server for embedded systems with some very basic 2D acceleration, e.g., openmoko's freerunner
<Fusin>
wpwrak: talking about freerunner. is there a channel which deals with freerunner here?
<Fusin>
ok, found ;)
<wpwrak>
;-))
<Fusin>
is called #openmoko :D
<Fusin>
still needs to update his fr
<Jay7>
kdrive is dead
<Jay7>
afaik
<wpwrak>
Jay7: dunno. i vaguely remember that it has been merged into x.org, but i'm not sure what specifically this means