<xiangfu>
wpwrak: small question. about milkymist screenshot. :)
<xiangfu>
"the framebuffer is basic progressive scan buffer using RGB565 pixel format"Â Â from the milkymist document.
<wpwrak>
xiangfu: sounds simple :)
<xiangfu>
"(unsigned int) height*width*2" is this buffer size just fit for RGB565 ?
<wpwrak>
xiangfu: i think progressive scan means that it's without interleaving
<wpwrak>
xiangfu: sounds good, yes. there may be some alignment at the end of each scan line, but you'll see this immediately when you get a screenshot. why the cast ?
<xiangfu>
sorry. what is the meaning of "why the cast" ?
<xiangfu>
wpwrak: I try to add the command to rtems. just read the /dev/fb and convert it to png file :)
<wpwrak>
xiangfu: (why the cast) why  (unsigned int) height*width*2  and not just  height*width*2  ?
<wpwrak>
xiangfu: the rest sounds good
<xiangfu>
wpwrak: I am taking the code form 'fbgrab' "for (i=0; i < (unsigned int) height*width*2; i+=2)"
<xiangfu>
the buf_size is like:Â Â size_t buf_size = 640 * 480 * 2;
<wpwrak>
but what would happen if you don't use a cast ?
<xiangfu>
I think it's same. with or without cast, in 640x480 solutions.
<wpwrak>
xiangfu: kewl. casts are always a bit scary :)
<kristianpaul>
bbl i think i screwup some pins of my ltp.. :/
<xiangfu>
wpwrak: can you talk some detail about cast? sometime "negative" will be consider a big integer. right?
<kristianpaul>
hmm. bad a,plitude still 2.4V..
<wpwrak>
xiangfu: yes. but that's not the main problem with casts. the big problem with them is that they tell the compiler to shut up. so if there is any real problem the compiler would warn about, it won't. that's why one should only use casts where they are really necessary.
<xiangfu>
wpwrak: thanks for the info.
<wpwrak>
np :) another issue with unnecessary casts is that they confuse anyone reading the code. because you then wonder what this cast may be doing, let there seem to be no reason. so you wonder if you actually understand what the code does, and so on. lots of headache :)
<xiangfu>
wpwrak: ok. I will check the code again. seems if there some 'headache' :)
<xiangfu>
wpwrak: thanks. remove another two useless cast. my rtems fbgrab finished. :)
<wpwrak>
kewl :)
<rjeffries_>
curious: does RGB565 mean 5 bit color frpth for red 6 got gtrrn and 6 for blue? in a 16 bit integer?
<rjeffries_>
crap 5 bit red 6 bit green 6 bit blue (color depth)
<xiangfu>
rjeffries_: yes.
<xiangfu>
5bit red,  6bit green, 5bit blue
<xiangfu>
565, not 566 :)
<rjeffries_>
thanks xiangfu I tyo far too often
<rjeffries_>
s/tyo/typo  lol
<kristianpaul>
xiangfu: (fbgrab) oh, is it working now?
<xiangfu>
kristianpaul: not test yet. just finished the code. :)
<xiangfu>
kristianpaul: do you know how to create the "MAC ADDRESSÂ Â Â Â Â Â Â Â (0x002200E0) /* within rescue BIOS */" image?
<kristianpaul>
yes
<kristianpaul>
crt0.S
<kristianpaul>
/home/paul/milkymist/software/bios
<aw>
xiangfu, so you knew already that how to build them all?
<kristianpaul>
make again, bios and rescue bios are created at same dir
<kristianpaul>
macadd is line 70
<wolfspraul>
kristianpaul: do I understand this correctly that xiangfu is working on screenshot feature? if so, can you try to take screenshots of the camera and lenses again? it's not super urgent, we can also wait until we have some more features...
<wolfspraul>
for example it would be great if we could show the video in 640x480 full-screen, if that is possible...
<wolfspraul>
step by step :-)
<kristianpaul>
i was checking how to increase vide-in size
<kristianpaul>
is not so hard
<kristianpaul>
just a pair of constants to change
<kristianpaul>
sure, i can take screenshots as soon xiangfu finish/test the tool :-)
<wolfspraul>
I bought some more cameras and lenses
<wolfspraul>
have to work through all this stuff a bit...
<wolfspraul>
too many now :-)
<wolfspraul>
need to digest...
<kristianpaul>
:-)
<wolfspraul>
kristianpaul: do you have what you need for your presentation/demo?
<xiangfu>
kristianpaul: oh. it's within the BIOS. should read more carefully :). I though it's a stand alone image.
<kristianpaul>
wolfspraul: yes i do
<kristianpaul>
xiangfu: is actualy same bios bin with and offset
<kristianpaul>
if i remenber well
<xiangfu>
? then some confuse. do you need flash this "MAC ADDRESS"
<kristianpaul>
you need to flash both bios and rescue bios
<kristianpaul>
as i said mac addres is an offset  of rescue bios
<xiangfu>
ok.
<xiangfu>
got it.
<kristianpaul>
./include/hw/flash.h:25:#define FLASH_OFFSET_MAC_ADDRESSÂ Â Â Â Â Â Â Â (0x002200E0) /* within rescue BIOS */
<kristianpaul>
ah, i think you already printed that, sorry  :p
<xiangfu>
how the bios-rescue got the mac address?
<xiangfu>
I found the bios how to read this mac address :). but didn't find who write the mac address to the FLASH_OFFSET_MAC_ADDRESS
<kristianpaul>
btw bios and bios-rescue have the mac
<xiangfu>
aw: yes. I think so :)
<kristianpaul>
so, you do as usual (urjtag), and bios will read the bios-rescue address + an offset where mac is stored
<kristianpaul>
you actually can confirm this with readmem command in urjtag
<kristianpaul>
xiangfu: for fbgrab, why i see R G B and alpha in the code? i mean there is a buffer or somethig for each basic color?
<wpwrak>
xiangfu: great, congratulations ! although the first version had nicely psychodelic colors ;-)
<wpwrak>
kristianpaul: now we can finally see what your cameras really do :)
<wpwrak>
xiangfu: btw, couldn't we just flash new kernels from linux with flash_erase/nandwrite ?
<wolfspraul>
yes, definitely. That's how I flash in the factory.
<wpwrak>
aha ! got the commands somewhere ?
<wolfspraul>
the only thing we cannot flash from Linux yet is u-boot, because the CPU will assume a 2048 byte page with 64-byte OOB etc. and we need a special little write program to bypass the 'real' 4096/128 oob/ecc creation...
<xiangfu>
wpwrak: /usr/bin/mtd.nn if you using 2011-02-23.
<wolfspraul>
that's just a 50-100 line program or script, but we don't have it yet
<wolfspraul>
so u-boot is currently not trivially flashable from inside Linux, at least a bootable u-boot :-)
<xiangfu>
there is a workaround. but it's not good. 1. dump the u-boot-spl. 2. cat u-boot-spl and new u-boot.bin to u-boot-nand.bin 3. flash that inside linux.
<wpwrak>
xiangfu: hmm, no, only older ones. in which package is it ?
<wolfspraul>
xiangfu: no worries, werner only wants to reflash the Linux kernel now.
<wpwrak>
tuxbrain: how are we doing with the data sheets ? i'm particularly curious about the one of the usb connector. the rest isn't so urgent. (for most of the components, it's either "anything goes" or "don't change" anyway)
<tuxbrain>
wpwrak: I have jus reclaimed it, let's see... btw, Can I deduce by the commits you have added support for the atben and also ZIgbee support on NN?
<tuxbrain>
is crossing his fingers?
<tuxbrain>
?->...
<wpwrak>
tuxbrain: not quite ;-) right now, the kernel can say "hello" to the card. then it fails to get any further status for some reason.
<wpwrak>
tuxbrain: also, the zigbee stack isn't supposed to work. i'll have to find out if there's enough to get wpan up.
<tuxbrain>
wpwrak: ok :) thanks for the tuxbrain level isue explanation (kernel say hello but card is not his friend)
<wpwrak>
good. now i'm making it all the way to the famous hang. very good. time for idbg :)
<methril_work>
get proud of wpwrak and his idbg
<wpwrak>
:)
<wpwrak>
aha. and now there's a little rootfs corruption. love these. i wonder if that has anything to do with usbboot producing an unbootable kernel about half of the time
<kyak>
now to do two things: pay for it and figure out what to do next with them :)
<wpwrak>
kyak: (11 days) wow, real snail mail :)
<kyak>
next time i decide to order something, i'll ask to disassemble it and ship separately by mail :)
<kyak>
cause Ben is still on his way for 17 days now :)
<wpwrak>
kyak: hmm .. a snail moves about 1-3 mm/s. let's say 2 mm/s. if a postal snail has an average workday of 8 hours, that would be 57 m/day. yeah, may take a while.
<lars_>
so the average garden snail could make amlost 400m per working day
<kyak>
the snail could catch the airplane
<kyak>
would be must faster in this case@!
<lars_>
i wonder how many snails it takes to carry one nanonote
<wpwrak>
lars_: (0.013 m/s) hmm, but if they hire athlete snails for postal work ?
<wpwrak>
lars_: (how many snails) kyak could find out by analyzing the slime traces on the package
<lars_>
wpwrak: do they hire athlete humans for postal work?
<wpwrak>
lars_: neither, i guess. they might go postal too quickly.
<kyak>
wpwrak: hm, trying to find that magic echo "0" > /proc/.. command to disable mmc and to prepare this slot for UBB.. Can't seem to find it on Wiki
<wpwrak>
tuxbrain: still nothing from the smt guys ?
<whitequark>
to everyone who thinks their postal system is bad: it isn't. russian one constantly delivers packages for me in 30-40 days (and the international part of that takes ~10 days. guess how they're delivering the package over a few km, in the same city, for around a month)
<whitequark>
of course all of they arrive broken and wet, too.
<kristianpaul>
:/
<wpwrak>
whitequark: what sort of wetness ? rain/snow ? seawater ? vodka ? urine ? vomit ? :)
<whitequark>
well, not THAT bad
<kristianpaul>
what? oh.. i was about to take lunch :|
<wpwrak>
(-:C
<whitequark>
i think that's just water
<wpwrak>
note to self: wrap shipments to russia in corrosion-proof plastic
<whitequark>
yeah, ST done that when sending their free developer boards
<whitequark>
worked perfectly
<whitequark>
and I still can't understand how they managed to jam a 3.5cm book just near its back. maybe they have a 20-ton press exactly for that purpose
<wpwrak>
whitequark: how are courier services like fedex, dhl, ups, etc., faster ?
<wpwrak>
whitequark: (20 ton press) maybe work in the russian postal service is a lot more fun than we all believe ;-)
<kyak>
whitequark: last time it took them ~16 days to deliver Ben (around a year ago). Now it's 17 already, i'm not even seeing the parcel registered here (and yeah, it's Russian post)
<wpwrak>
i'm beginning to understand why wolfgang wants a distributor in russia ...
<whitequark>
(about fedex etc.) they're generally better, but (a minor problem) sometimes that doubles the price and (a major one) they're not always available as an option. e.g. when I was buying that book from PragProg, there were some troubles (through I can't quite remember which exactly)
<kyak>
it's brain, blocking bad images :)
<whitequark>
wpwrak: that would be very nice. maybe I'd even buy one (ahem... don't know what to do with that :) and I already have three devices which are at least not worse than Ben by hardware characteristics. except the nice case; well, that matters!)
<wpwrak>
whitequark: ah yes, for less expensive items, like books, it may get tricky.
<Jay7>
hehe.. russian post again :)
<Jay7>
they delivered my nanonote in 60 days exactly
<Jay7>
from USA
<wpwrak>
kyak: seems that you can relax :)
<whitequark>
60 days. that's an achievment even for them
<kyak>
shipments from USA took distinguishly long
<Jay7>
kyak: shipment from USA to Moscow is fast enough
<Jay7>
but then customs
<Jay7>
and then in-russia delivery
<Jay7>
which is most scary thing
<kyak>
Jay7: it can travel around Moscow for quite long. And not get delivered after all. Recently a friend of mine had to go to their warehouse and search for his parcel himself
<Jay7>
kyak: known thing
<wpwrak>
kyak: did he find it ? after how many days ?
<Jay7>
my wife encountered this already too :)
<lars_>
i guess i should never complain again, when it takes the german post 3 days to deliver my package
<kyak>
wpwrak: yeah, he did find it.. after several days of phone calls, claims and wasted time
<whitequark>
lars_: you live in postal heaven
<wpwrak>
kyak: sounds like pure joy
<wpwrak>
(reset problem) ah no ... ben just hangs sometimes after "starting u-boot" (following an idbg-commanded hard reset). odd.
<lars_>
maybe the reset pulse is to short
<lars_>
and some internal registers weren't reset
<whitequark>
may I ask why Ingenic processor was selected for ben?
<wpwrak>
lars_: must be something like this, yes. or maybe the slope is not steep enough. ah well. something to worry about another day.
<wpwrak>
now .. why the heck can't it open /dev/null when i compile in my atben driver. grmbl grmbl.
<kristianpaul>
whitequark: Ben was already made before take time to select the processor
<kristianpaul>
I mean ben actually is also a digital color dictionary that you can find in the chinnese market
<kristianpaul>
wolfgang nock the doors of ingenic in order to make things more open (dunno the state of this)
<kristianpaul>
and also take like 1 year to get linux/openwrt/menus/apps as we know it today
<kristianpaul>
of course i wonder if wolfgang had other alternatives at that time
<kristianpaul>
i remenber i saw a hanvon ebook in xiangfu's blog also in qi/openwrt
<tuxbrain>
kristianpaul: also with ingenic chip :P
<lars_>
tuxbrain: i think he was wondering if there weren't any alternatives to the device not to the chip
<kristianpaul>
yup lars_
<tuxbrain>
hides ashamed
<kristianpaul>
tuxbrain: hey no, chip may also vary, and is a good point (chip alternatives for wolfgang at that time)
<kristianpaul>
still like the idea of a "nano-ebook" :-)
<lars_>
i think it is to late for ebooks. at least for ebooks with epaper
<wpwrak>
a general portable device (pda, smartphone, etc.) with epaper would be nice, though. the patents should slowly start to expire, so the technology ought to become accessible ...
<tuxbrain>
a copyleft e-paper device will be really cool
<wpwrak>
lars_: when i boot the origin/jz-2.6.38 kernel on openwrt, i get /etc/init.d/rcS: line 17: can't open '/dev/null'
<wpwrak>
lars_: what rootfs do you use ? (i have opennwrt Ben_NanoNote_2GB_NAND/2011-02-23, but i've seen this also with an other version)
<lars_>
wpwrak: i get the same error
<wpwrak>
lars_: i first thought i had just damaged my rootfs, so i reinstalled everything. don't have the original version.
<wpwrak>
ah ! :)
<lars_>
but so far i haven't seen any negative consequences
<wpwrak>
hmm, i don't get anything on the serial console
<wpwrak>
GNUtoo|bug20: my system boots now properly (after making the kernel look for /etc/preinit). now i have to cross-compile the user space tools, which in turn need libnl ...
<GNUtoo|bug20>
yes openwrt has strang patches
<wpwrak>
yup :)
<GNUtoo|bug20>
there is one which says
<GNUtoo|bug20>
wait while openwrt is booting
<GNUtoo|bug20>
or something like that
<GNUtoo|bug20>
instead of outputing an error
<wpwrak>
nice ;-)
<GNUtoo|bug20>
it's a kernel patch
<wpwrak>
somehow i don't think we'll see that one in mainline anytime soon ;-)
<GNUtoo|bug20>
basically I had that message on serial on my wrt54gsv4
<GNUtoo|bug20>
lol
<GNUtoo|bug20>
the pre-init is strange too
<GNUtoo|bug20>
cound't they do CONFIG_CMDLINE="init=/etc/preinit"
<xMff>
preinit is needed to implement failsafe
<GNUtoo|bug20>
ok
<GNUtoo|bug20>
needs to sleep
<wpwrak>
xMff: mv /sbin/init /etc/init; mv /etc/preinit /sbin/init  ?
<xMff>
wpwrak: I don't know why this name was choosen in the first place, many of that is historical stuff, dating back to when openwrt was a hack for wrt54g routers :)
<xMff>
and the commandline handling is a headache on various architectures, mainly due to braindead oem bootloaders
<wpwrak>
xMff: the kernel already tries a number of paths. so you could have used just some of these, i.e., /sbin/init for the first choice, /etc/init for #2, and there's even a /bin/init for #3
<xMff>
wpwrak: as I said, I don't know why it was choosen, maybe because it was perceived as kind of special init script
<wpwrak>
nice. libnl has pretty radical api changes in version 3. and the zigbee stuff seems to be written for version 1
<xMff>
hm are you sure they're that radical? I only recall two common changes
<xMff>
ah hm, I think what I meant was 3 vs 2
<wpwrak>
xMff: nl_handle changed to nl_sock
<xMff>
yes
<wpwrak>
xMff: and the error handling now requires an error number, while they apparently had an implicit errno-like one before