<wpwrak>
zedstar: i can't quite grasp what it does, but it looks cool :) and yes, the music is good, too
<kristianpaul>
zedstar: actually i wonder how trusty is to measure vibration in your future aplication
<jow_laptop>
kyak: do you know whether gemenu2x writes a pid file?
<wolfspraul>
good morning everybody
<wolfspraul>
DocScrutinizer: you there? remember you suggested supercaps once?
<wolfspraul>
instead of batteries? I forgot the details... I'm looking a bit into rtc's upon larsc feedback that his m1 forgets the time whenever he turns it off
<wolfspraul>
so far I've found that there are thousands of discrete rtc chips at digikey, that we could probably implement an rtc in the Milkymist SoC itself, that we would probably want the cheapest and simplest chip that only does what the fpga itself cannot do (to track time when power is off)
<wolfspraul>
i2c and spi seem to be common interfaces, but I also found 1-serial and other serial interfaces
<wolfspraul>
then I thought of your supercaps :-)
<wolfspraul>
because in any way power has to come from somewhere...
<wolfspraul>
would rtc be a possible application? maybe I look for a tiny rtc chip that has a battery/supercap included? or is my thinking all wrong?
<kristianpaul>
(rtc chip) great idea !
<wolfspraul>
yes
<wolfspraul>
we can implement the part with a lot of features in the SoC, somehow I think the only thing we need outside is a new tiny and cheap chip with some ability to hold power and track the time
<wolfspraul>
no interrupts, no high-precision stuff, nothing. all that could come from the SoC (theoretically)
<kristianpaul>
well, keep the time is just enought :)
<kristianpaul>
(high-precision) well, werner already show  us that ntp can help a lot on this
<wolfspraul>
once you assume network connectivity you don't need an rtc at all
<wolfspraul>
I'm looking for a very very simple fix. an unconnected m1 looses the time on every shutdown.
<kristianpaul>
yeap, i like that :)
<wolfspraul>
because we have an fpga, we don't need a sophisticated rtc chip with lots of bells and whistles (interrupts, alarms, high-precision, etc)
<wolfspraul>
so I want to understand this supercap thing more
<wolfspraul>
that + a super simple time tracker (poll only) is all we need
<wolfspraul>
kristianpaul: you build milkymist software a lot, how computing intensive is it?
<wolfspraul>
I am thinking about upgrading the buildhost
<wolfspraul>
for one, the nanonote builds keep getting slower (31 hours now)
<wolfspraul>
and I can only see us building more software and on a faster/more regular schedule in the future
<wolfspraul>
and then I want to start adding milkymist builds too
<wolfspraul>
including bitstream builds
<wolfspraul>
any thoughts?
<wolfspraul>
right now we have an AMD Athlon single-core machine. optimized well but fairly basic server power. I chose a cheap one for 29 EUR / month.
<kristianpaul>
xst, cant do multithread
<wolfspraul>
is there anything a buildhost could help you with? would you use it for something if it had certain power?
<kristianpaul>
as default..
<wolfspraul>
that's ok, it's only one part
<wolfspraul>
even if we go to a quad-core, it will constantly build enough stuff I think
<wolfspraul>
I also need to get this 31 hour thing down
<wolfspraul>
I'm curious about your Milkymist perspective
<wolfspraul>
anything a buildhost could do for you?
<wolfspraul>
how long do the builds take?
<kristianpaul>
15minutes for my GPS porpuses
<kristianpaul>
as i use a minimac soc
<kristianpaul>
buildhost not for me at least for bitstream.. unless it speedup sinthesis to 5minutes, that will be cool :)
<kristianpaul>
and after i send a mail to automate build..
<kristianpaul>
he,  i lile dream ;)
<kristianpaul>
s/lile/like
<kristianpaul>
s/minimac/minimal
<wolfspraul>
hmm
<wolfspraul>
ok
<wolfspraul>
that helps
<wolfspraul>
there could be a web interface to kick off a build, or email interface for Werner, of course
<wolfspraul>
url to source repo, hit the build button, done
<wolfspraul>
a few minutes later the binary is available for download
<kristianpaul>
about that 31minute building i wonder if you need alwats build all from scratch?
<wolfspraul>
it's not so much about need
<kristianpaul>
i mean you change kernel and toolchain version in every build?
<wolfspraul>
it's about minimizing human working hours and maximizing machine power
<kristianpaul>
sure
<kristianpaul>
and speed up
<wolfspraul>
you can always compensate for less machine power with more manual hours spent, but who wants that
<wolfspraul>
I think we want it the other way round ;-)
<kristianpaul>
15minutes still... arggh :)
<wolfspraul>
when we started the buildhost, it wasn't clear whether it would be used at all
<wolfspraul>
but now we have multiple people using it regularly
<wolfspraul>
and with Milkymist the need will only go up
<kristianpaul>
but compared to 40minutos for a full soc build, well :-)
<wolfspraul>
and it's used for schhist and maybe brdhist one day
<roh>
wolfspraul: if you upgrade.. check for ram. that also speeds things up considerably (disk cache)
<roh>
eq4 is a good deal
<kristianpaul>
on my computer.. a 2.6Ghz amd sempron 1gb. dunno numbers from lekernel ?
<wolfspraul>
yes I was thinking about eq4
<kristianpaul>
need to upgrade to eq4 some day...
<wolfspraul>
it's an x2 now, the cheapest physical hw I could get
<roh>
wolfspraul: i know ;)
<wolfspraul>
I would probably also setup the new one with Fedora
<kristianpaul>
:-D
<wolfspraul>
I tested Fedora a little and it looks good. I like their more speedy release schedule.
<wolfspraul>
selinux is causing hickups sometimes, but so far I've been able to solve them quickly
<kristianpaul>
kill it !
<kristianpaul>
:)
<wolfspraul>
hopefully that wouldn't cause trouble to buildhost users (selinux)
<wolfspraul>
well, I like security
<wolfspraul>
I have no big pro/con about selinux in particular, just a user.
<kristianpaul>
insecurity is among us ;-)
<kristianpaul>
sure
<wolfspraul>
roh: I was hoping for an eq4 price reduction or improved hw specs, but didn't come :-)
<wolfspraul>
I want more power, more ram, ssd, etc.
<wolfspraul>
eq is old now and hasn't been upgraded in a while. maybe they come out with something new soon...
<kristianpaul>
so for now i see no diference if build host speed and my computer to get sinthesize stuff
<kristianpaul>
s/if/in
<roh>
wolfspraul: well.. that usually comes with 'new series' and the old ones get dumped out cheap.. as happened with the ds series
<wolfspraul>
ye
<wolfspraul>
yes
<wolfspraul>
I know. So I was hoping for something new. eq is old.
<kristianpaul>
can we test driver a build in that new server?
<roh>
what new should there be after i7 cpus?
<wolfspraul>
don't understand
<kristianpaul>
anyway i guess you upgrade to quadr core
<kristianpaul>
i mean before make the move
<wolfspraul>
no not really.
<wolfspraul>
but you could get a server and cancel if after a month.
<wolfspraul>
the amount of working hours you would put into this test would weigh far more than the 100 EUR or so you would still need to pay to hetzner in that case.
<kristianpaul>
100EUR?? nah... i still with my own build server :)
<wolfspraul>
no you asked about a test
<kristianpaul>
helps have a laptop and mostly comand line tools for the rest of the tasks :)
<kristianpaul>
yeah, but better not ;)
<wolfspraul>
the easiest way to test at hetzner is to just get the machine, do what you want, and if it's not good cancel after 1 month
<kristianpaul>
100eour is not a nice number to me :)
<wolfspraul>
sure, it costs money
<kristianpaul>
fot this test
<wolfspraul>
yes of course. but if we need a bigger and better buildhost, we'd just do it. upgrade from the current x2 (29 EUR/month) to something better...
<wolfspraul>
no test
<roh>
still cheap.. i couldnt provide the hw including support and power as well as ethernet for that money. not even if i got the space and ip for free.
<wolfspraul>
just upgrade and we know it'll be more powerful, from the specs
<wolfspraul>
sure you cannot, but hetzner has scale and is managed quite professionally
<roh>
ack. just ressurected chandra for openmoko
<wolfspraul>
wow, Linux seems to have support for ca. 100 rtc chips :-)
<wolfspraul>
just looking at drivers/rtc
<lemay>
avast
<wolfspraul>
lemay: hey there
<kristianpaul>
wb lemay :)
<lemay>
I brought home 'Understanding GPS Principles and Applications' Edited by Elliot Kaplan
<lemay>
and GNSS Applications and Methods, by Gleason and Gebre-Egziabher
<kristianpaul>
those books have topics related to software aprouch?
<lemay>
they're textbooks with all the standard approaches
<DocScrutinizer>
wolfspraul: yes, I suggested supercaps for a number of good tested purposes and for some nonsense purposes (like battery swap buffering for phones)
<DocScrutinizer>
for both GTA02 and RX51/N900 the supercap alternative for powering RTC has been implemented and I got reports it works flawlessly
<DocScrutinizer>
I strongly discourage chips with battery built in, afaik there's only been dallas chip and I frown at it
<wolfspraul>
ok great, can you point to a supercap that could work to power an rtc?
<DocScrutinizer>
I think the guys that modded N900 followed my suggestion for 2nd URL, the GTA02 reworks I dunno exactly which supercap-buttoncell got used for that, maybe the first URL bottom-of-page type
<wolfspraul>
great, thanks
<wolfspraul>
rtc chips seem to have all sorts of features like square wave output, watchdog timer, trickle charger. interesting.
<wolfspraul>
no idea what these things are good for :-) well. the watchdog timer makes sense.
<DocScrutinizer>
nota bene the rationale for using this supercap buttoncels instead of proper LiIon cells comprised the fact that on a phone you usually _swap_ battery and thus need bupbat power for some couple of minutes only. Those caps can not power the RTC for months or years as the LiIon cells do
<wolfspraul>
need to check how much power they can hold vs. lowest power rtc
<wolfspraul>
but of course, understand
<wolfspraul>
DocScrutinizer: what is a square wave output or trickle charger in an rtc good for?
<wolfspraul>
reading about trickle charger now...
<DocScrutinizer>
square wave output usually to clock other low power components like e.g LP5521 indicator LED flasher
<wolfspraul>
the rtcs I find so far seem to want about 250-300 nA at 2V
<DocScrutinizer>
GSM modems also frequently have a 32kHz xtal  to keep the shedule during deepsleep (see #1024 where that clock generator was flawed by our layout)
<wolfspraul>
that's what they mean with 'trickle charging'
<DocScrutinizer>
\o/
<wolfspraul>
does that mean an rtc that does not support trickle charging is harder to connect to a supercap? I guess they added a little bit of circuitry inside this one...
<DocScrutinizer>
well, afaiu the super cap is a working replacement for LiIon cells, and should handle all chips' chargers designed for LiIon. Chips that have no charger at all are designed for primary cell power source and I strongly suggest this variant whenever you can afford to have a holder for a CR2016 (or similar) LiIon primary cell on your PCB and housing allows access to that cell to swap it
<DocScrutinizer>
no option for neither freerunner nor N900 obviously
<DocScrutinizer>
time for 12648430Â Â Â Â
<wolfspraul>
DocScrutinizer: ok, the taiyo yuden supercap has a capacitance of 60,000 uF
<wolfspraul>
how long can that power an rtc needing 200nA@2V... calculating :-)
<DocScrutinizer>
yep, aka 60mAs/V
<DocScrutinizer>
Vtop 2.8V, Vend 1.5V Vdelta 1.3V ergo 60*1.3 mAs capacity
<DocScrutinizer>
60 * 1.3 / 0.003(mA) = seconds such a cap can power your RTC
<wolfspraul>
looks like a year?
<wolfspraul>
ok, I got 1000 wrong somewhere
<DocScrutinizer>
433 minutes?
<wolfspraul>
yes, about 7h
<wolfspraul>
ok, interesting
<DocScrutinizer>
honestly, if your housing ME and the PCB size (and audience/usecase) allows, better go for primary cells
<DocScrutinizer>
as virtually all PC mainboards do today
<wolfspraul>
primary cells? what do you mean?
<DocScrutinizer>
but, use, dispose
<DocScrutinizer>
buy
<DocScrutinizer>
non-rechargable swappable cells
<wolfspraul>
you mean like the round watch batteries CR2016 and such?
<wolfspraul>
how does a desktop PC keep the rtc powered? or a notebook - how long can you take out the battery without loosing the rtc?
<roh>
wolfspraul: usually also lithium cells
<roh>
either solder-on or as connected pack with a short cable
<roh>
they are good for 5-10 years. and one can replace them after that. the one on my tp600e went empty at some point and i just replaced them by some new ones and used new shrinking tube after resoldering the cable
<DocScrutinizer>
moin roh! how's chandra business? OM community is suffering
<wolfspraul>
which cell was it? CR20xx ?
<roh>
sometimes its also 2 cells, but that was on older models
<roh>
DocScrutinizer: should be working again
<DocScrutinizer>
OOOH
<roh>
please check/test
<wolfspraul>
so basically the supercaps are good for what? only a couple hours it seems
<DocScrutinizer>
\o/
<DocScrutinizer>
works
<wolfspraul>
even on a mobile device you probably better have 2 batteries, one to power the whole device, and a cr2016 or so for the rtc?
<DocScrutinizer>
mail.om at least
<roh>
wolfspraul: depends on the power use. i guess they wont survive a month-long period without recharge while driving a rtc
<wolfspraul>
of course that's big. if space is a concern the supercap may be enough if people switch batteries immediately.
<wolfspraul>
roh: we just calculated it to be ca. 7h
<DocScrutinizer>
wolfspraul: not exactly a CR2016, but maybe a CR1510
<wolfspraul>
ok even smaller, nice
<roh>
wolfspraul: most simple mobiles (featurephones) dont have any batteries i know of. so either they survive on a cap or just dont have time after swapping battery
<roh>
i think my motorola survives a few minutes and then i have to reenter time manually
<DocScrutinizer>
usually the latter
<wolfspraul>
or they get the time from the network, I would think
<wolfspraul>
for a connected device, if that's the only purpose of the rtc
<DocScrutinizer>
also common
<roh>
mainboards sometimes even accept large coin style cells like cr2032
<roh>
in a holder for easy replacement
<roh>
atx stuff
<DocScrutinizer>
usually CR2016 on mainboards of PC
<DocScrutinizer>
err, maybe I'm wrong
<roh>
wolfspraul: in germany afaik only one network transmits a time out of 4. and the quality (precision) is also not that good everywhere
<DocScrutinizer>
could also the 3.2mm 2032
<roh>
some networks get the utc vs local time wrong etc.
<roh>
DocScrutinizer: thats what i would use if i have the space
<wolfspraul>
2032 for what?
<wolfspraul>
for the rtc sounds a little crazy, or you mean for the whole device?
<DocScrutinizer>
yeah, 2016 and 2032 most common and easily available nowadays
<roh>
common, available everywhere from many sources, enduser compatible replacement process, cheap, easy to use schematic wise
<roh>
wolfspraul: for the rtc/whatever needs to survive power off or battery change (depending on device)
<wolfspraul>
wow 2032 looks overkill for that
<DocScrutinizer>
for 'small' devices there are other formfactors like CR1512 (15mm dia, 1.2mm thick) and others
<DocScrutinizer>
CR1208?
<roh>
wolfspraul: dont underestimate the factor of handling and sourcing on that. if its too small or to weird, endusers cant get it and have mechanical problems in handling when needed
<wolfspraul>
agreed but 2016 is very common
<wolfspraul>
how long could that power a 200nA rtc?
<DocScrutinizer>
aeons
<DocScrutinizer>
;-)
<roh>
80-90mAh seems common on quality cells (checked sanyo and energizer specsheets)
<DocScrutinizer>
I'd guess a CR2032 has several 100s of mAh
<DocScrutinizer>
so 10k to 100k hours
<roh>
2032 is 240mAh
<DocScrutinizer>
240 / 0.002
<DocScrutinizer>
err 0.0002
<roh>
13years
<wolfspraul>
13 years for 2032, probably a little less than half for 2016, let's say 5-6 years
<roh>
136 years at 0.0002
<roh>
13 at 0.002
<roh>
for a cr2032
<DocScrutinizer>
aeons, toldya
<roh>
i bet self-discharge is a bigger influence on it running flat then
<DocScrutinizer>
sure
<roh>
meh. its late/early (8:45 am) .. need to head home catch some sleep
<DocScrutinizer>
wolfspraul: if you by any chance can avoid soldered battery and allow user to access it to swap, go for whatever size of CRxxyy primary cell. Otherwise go for supercap, as the soldered LiIon bupbat seem a broken technology
<DocScrutinizer>
roh: :-D have a pleasant rest, and thanks for fixing chandra
<wolfspraul>
oh sure, no worries
<DocScrutinizer>
wolfspraul: my Sony scoopman NT-1 had a CR1220 for RTC, and a very "expensive" door mechanism to access it to swap. Alas there must've been a flaw in hw, as that friggin cell been empty every 6 months
<wolfspraul>
I am not planning anything in particular anyway, just trying to understand the ballpark numbers for different technologies
<wolfspraul>
but of course, soldered li-ion sounds wrong by design
<wolfspraul>
supercap is fine, but has use-case limitations
<DocScrutinizer>
yup
<wolfspraul>
once you are in the 20xx or 15xx area it's probably mostly about size and how common / easy to get something is, even after 5, 10 years
<wolfspraul>
all understood
<DocScrutinizer>
supercap fine for devices that most usually have a main battery, to survive swapping of that main battery only
<wolfspraul>
so a typical 2011 CR2032 cell can theoretically power a 200nA rtc for 136 years?
<wolfspraul>
not 13
<wolfspraul>
of course self-discharge will be the much bigger factor
<wolfspraul>
is it 1% / day? must be less for those I would think
<DocScrutinizer>
nah, more like 10% per year
<wolfspraul>
I thought I had read something about 1% / day somewhere
<wolfspraul>
ah ok
<DocScrutinizer>
1% / day is for LiIon rechargable, not for primary
<wolfspraul>
primary is which type (chemical)?
<DocScrutinizer>
primary is use-once-and-discard
<wolfspraul>
also lithium?
<DocScrutinizer>
yep
<wolfspraul>
what's the difference between 'primary' and li-ion?
<wolfspraul>
or are both li-ion and one is rechargeable and the other not?
<DocScrutinizer>
different semantic domain
<DocScrutinizer>
yes
<DocScrutinizer>
CR2032 is a Li(Ion)-cell, but not rechargable (by design, though in fact they are ;-D)
<DocScrutinizer>
so it's a primary cell
<DocScrutinizer>
a BP-5L Nokia battery is a rechargable LiIon (or LiPo) so it's not a primary
<DocScrutinizer>
primary is the opposite of rechargable
<wolfspraul>
if it's the same chemical, why does a primary cell have a self-discharge of 10%/year, but a rechargeable 1%/day ?
<DocScrutinizer>
http://en.wikipedia.org/wiki/Primary_cell >>A primary cell is any kind of battery in which the electrochemical reaction is not reversible, rendering the cell non-rechargeable.<<
<DocScrutinizer>
because it's not exactly the same cell chemistry
<DocScrutinizer>
different electrolyte, different separator
<DocScrutinizer>
different mechanical (and also somewhat chemical) electrode design
<DocScrutinizer>
in a primary cell you for example don't need much auxiliary material to keep electrode mechanical shape, the whole electrode can be built by virtually massive Lithium
<DocScrutinizer>
charging such a cell won't result in an electrode of same shape as the original
<DocScrutinizer>
this plus a lot of subtle diffs make a cell primary, which usually also results in better capacity on same formfactor than a rechargeable cell would offer
<ignatius->
Anyone know how to access/read a broken (CRC, UBI errors) Debian Nanonote system? It was working, but something happened, not sure what, and now it won't boot.
<ignatius->
Something that doesn't let the system boot the kernel, without a kernel panic. I've tried the "root=" append line, no luck.
<wolfspraul>
DocScrutinizer: understand, thanks!
<DocScrutinizer>
>>Primary batteries are useful where long periods of storage are required; a primary battery can be constructed to have a lower self-discharge rate than a rechargeable battery, so all its capacity is available for useful purposes. Applications that require a small current for a long time, for example a smoke detector, also use primary batteries since the self-discharge current of a rechargeable battery would exceed the load current ...
<DocScrutinizer>
<<
<ignatius->
Is it possible to access the Nano through the USB connection?
<wolfspraul>
we had some plans but I don't think they are fully implemented yet
<ignatius->
Ok.
<wolfspraul>
such as loading a rescue system via usbboot directly into memory
<wolfspraul>
you can try to boot from the memory card though
<wolfspraul>
how about that?
<ignatius->
Not sure on how to do that.
<wolfspraul>
as long as u-boot still loads that should work
<ignatius->
I tried to "HOWTO" on the official website, it needed me to be on the machine while creating the bootable card.
<DocScrutinizer>
I'm sure there's an easy way to create the card on arbitrary PCs
<DocScrutinizer>
creating the card on Ben just described as a convenience thing
<ignatius->
Nod.
<DocScrutinizer>
(no Ben here, so I talk outa my a...)
<wolfspraul>
ignatius-: that page is about updating the Ben from a memory card, there's another one about booting, but I cannot find it either :-)
<ignatius->
:/
<kyak>
jow_laptop: nope, gmenu2x doesn't write a pid file. Probably it used to, when we started it via start-stop-daemon. But now it just spawns from inittab
<wolfspraul>
kyak: how do you feel about upgrading the buildhost to a more powerful machine? is it worth it?
<kyak>
wolfspraul: yeah, why not? Upgrading is always worth it. For now, the build for Ben takes more than 24 hours. It would be great if we could "fit" it into 24 hours
<kyak>
from the other hand side, if we look at the rate of commits to openwrt-xburst.git and openwrt-packages.git, it is longer than 24 hours
<kyak>
so basically consequitive images are very often the same
<kyak>
in this thinking, updating to a more powerful machine doesn't make sense
<kyak>
at the end, it also depends on the price you are going to pay for upgrade :)
<wolfspraul>
kyak: he. interesting point about commit intervals :-)
<wolfspraul>
but I also want to make the build experience snappier and more fun for people who use the buildhost actively
<wolfspraul>
and if you commit something specifically, you may have to wait 2 days until you can try: not good
<wolfspraul>
I'll think about it. the monthly price would go from 29 to 49 EUR. Maybe I wait for a new server line to be introduced by the hoster.
<kyak>
wolfspraul: good :)
<kyak>
wolfspraul: the full boot is speed up :)
<kyak>
i press the button once, and the thing just powers on at the exact same moment
<kyak>
goes through the whole boot sequence
<kyak>
you could try it yourself, since poke is avaivable for quite some time now
<DocScrutinizer>
wolfspraul: would it be feasible to cache some pieces, so a build wouldn't need to run 24h+ to build same cruft over and over again? Sounds kinda silly
<DocScrutinizer>
I mean even a complete kernel build for maemo takes <3h on my 1.8GHz dual core pentium laptop
<kyak>
DocScrutinizer: the point of build is to build from scratch
<kyak>
incremental builds are not interesting
<DocScrutinizer>
I'd not expect a buildhost to build a "new" (in fact same old) kernel, when all I did was correcting a typo in ls --help
<DocScrutinizer>
nevermind, I got not the faintest clue what you guys are doing there on your buildhosts
<kyak>
it had been proved several times that change in one place can lead to strange results in other places. And using "cached" results leads to unpredictable things
<DocScrutinizer>
hmmm o.O
<kyak>
yeah, just search for "build from scratch" in irc logs
<DocScrutinizer>
I'm out, not intending to bug you with noobish musing
<DocScrutinizer>
I easily can agree on building core system in one run is a clean easy to understand thing
<DocScrutinizer>
still 24+ hours? WTF!
<DocScrutinizer>
whatever, I'm out again
<wolfspraul>
kyak: poke? you mean a tool I can use to write that rtc register manually?
<wolfspraul>
are we setting it automatically in the latest builds?
<kyak>
wolfspraul: yeah, that tool. THis is not yet done automatically..
<kyak>
i suggested xiangfu to include it in start script
<wolfspraul>
hmm, ok :-)
<wolfspraul>
amazing that we haven't included something so nice right away
<wolfspraul>
the image release cycles are too long
<dvdk>
do we need poke?  I guess dd of=/dev/mem bs=1 count=1 seek=0xblabla would work, too :)
<dvdk>
wait, no, with I/O mem it won't.  But in gforth it can be scripted.
<dvdk>
well gotta go
<ignatius->
Anyone know how to make a bootable SD card?
<ignatius->
After installing the boot loader and the userland on the SD card, upon booting, I get a garbled screen, that says somehting like "In: serial / Out: lcd / Err: lcd / Hit any key t  xc"
<wolfspraul>
where did you get the binaries you put on the memory card from?
<ignatius->
(Couldn't find instructions on the main qi site)
<wolfspraul>
kyak: do you know where the instructions for booting from the memory card are?
<ignatius->
Thanks for answering. I appreciate it.
<ignatius->
I've been having problem after problem... all I wanted at first was a custom kernel, with certain loadable modules. And this crap happens.
<wolfspraul>
well custom kernel is quite something to start with
<ignatius->
Compiling kernel after kernel.
<ignatius->
Yeah. True.
<ignatius->
I've found that the new "qi kernel" (vanilla?) supports the 2GiB NAND. I'm guessing the OpenWRT team or whoever patches it to support less.
<ignatius->
So, i've been going with that kernel. Still have to get the KS7010 driver working, too.
<wolfspraul>
oh, wow
<wolfspraul>
that's an ambitious goal
<ignatius->
I had it all working at once. Then it got screwed up somehow.
<ignatius->
I (stupidly) compiled the kernel, and it did everything I wanted it to do, then, I think I must've deleted that source tree, and have been looking for it for a few weeks now.
<wolfspraul>
hmm. yeah. painful.
<ignatius->
My goal was to have a smaller startup font. :/
<wolfspraul>
unfortunately there is so much activity in the kernel that I cannot really follow. I just hope the images coming out of the automated builds work :-)
<ignatius->
Nod.
<ignatius->
I think the Ben Nanonote should be a lot more popular. Even amongst the Dingoo A320 crowd.
<ignatius->
It's really an awesome little gadget.
<wolfspraul>
and you say this after weeks of struggling :-)
<ignatius->
Heh. Yeah.
<ignatius->
I can't wait for the successor.
<ignatius->
(If there will be one)
<ignatius->
But, yeah. My goal is to get to where I was before. An ultra small WIFI device that can do more than a smart phone.
<kyak>
wolfspraul: not sure where the instructions are. But this is pretty simple
<kristianpaul>
kyak: was is the porpuse of OpenWrt Image Builder?  i touhgt it once have a basis systems compiled allowed to crosscompile other packages with no need to recompile WHOLE system again..
<kyak>
kristianpaul: huh? you can do incremental builds if this is what you are asking. THe purpose of buildhost, however, is to run nice and clean build from scratch
<kristianpaul>
yes,  incremental builds, i like how it sounds :)
<kristianpaul>
yes i undertand that buidlhost is for that.. jsut wondering if its needed all time, i already guess it is
<kristianpaul>
as i tought makefiles allowed to recompiled what just changed to no more..
<kyak>
sure. This is what you do at home :)
<kyak>
but not on buildhost, from my understanding
<wolfspraul>
but anybody can use their user account on buildhost for whatever compilation they want
<kyak>
yeah, i was just talking about the automatic builds running via cron
<kristianpaul>
wpwrak: can you http/ping 216.239.32.2 ?
<ignatius->
Apparently, that is the same exact version I had installed beforehand.
<kyak>
can't be
<kyak>
you told you had 201104
<kyak>
but you need a version later than 27th of May
<ignatius->
Well, that's the version it says when I do a "xbboot -v"
<ignatius->
I even tried booting the Nanonote with F1... same exact errors as before.
<kyak>
have you read the messages on mailing list i pointed to? Do you have the same errors?
<ignatius->
Yes.
<kyak>
and how do you know it is exactly the same version that you had before?
<ignatius->
Because I did a "xbboot -v" then, too.
<kyak>
this is nothing :)
<kyak>
it shows 201104 to me, too
<ignatius->
Hmm.
<ignatius->
Why the errors, than?
<kyak>
anyway, now that you have the version from 2011-05-30, try flashing the latest bootloader
<ignatius->
I did.
<ignatius->
I'll try again, though.
<kyak>
btw. Where is the uImage you are using coming from?
<kyak>
you could use the latest uImage form openwrt and see how it boots
<ignatius->
The MuffinMan site.
<kyak>
even with jlime rootfs, this should work
<kristianpaul>
weee !
<ignatius->
Same errors as before.
<ignatius->
Ok. I'll try an OpenWRT image.
<kyak>
ignatius-: could you paste the output when flashing the bootloader?
<ignatius->
Sure.
<kristianpaul>
2 second less of booting :)
<kyak>
ignatius-: also, are you sure you have this partition on sd card as the first partition? Not the whole sd card formatted as ext2? In the latter case, you should hold the "M" while powering on
<ignatius->
usbboot version 201104 - Ingenic XBurst USB Boot Utility (c) 2009 Ingenic Semiconductor Inc., Qi Hardware Inc., Xiangfu Liu, Marek Lindner This program is Free Software and comes with ABSOLUTELY NO WARRANTY.  Now checking whether all configure args valid: YES Current device setup information: Crystal work at 12MHz, the CCLK up to 252MHz and PMH_CLK up to 84MHz SDRAM Total size is 32 MB, work in 4 bank and 16 bit mode Nand page pe
<ignatius->
Ack.
<ignatius->
Hopefully that looks better to you.
<ignatius->
Execute command: nprog 0 openwrt-xburst-qi_lb60-u-boot.bin 0 0 -n  Programing No.0 device, flen 623096, start page 0...  CPU data: Boot4740  Erasing No.0 device No.0 flash (start_blk 0 blk_num 2)......  Finish! Return: 00 01 00 00 00 00 00 00 (position 2)  Force erase, no bad block infomation!  Size to send 623096, transfer_size 524288  Image type : without oob  It will cause 2 times buffer transfer.  Writing NAND page 0 len 524
<kyak>
ignatius-: your messages are truncated.. better paste somewhere
<ignatius->
Nod.
<ignatius->
Hold on.
<ignatius->
Pfft. Of course. My shell account is down.
<roh>
wolfspraul: what do you think about the future if ingenic for us?
<roh>
i think if we ever want to continue the way we should get the newer soc working on existing hw first before building our own. makes testing a bit easier maybe
<wolfspraul>
roh: just a hardware supplier to me. I like how successful we are with the Linux kernel, mostly Lars and mth and a few others. So that's a real treasure I think that we need to maintain well.
<wolfspraul>
if I would consider using any other Ingenic chip, I would look at the state of support in that kernel first
<wolfspraul>
when you say "get the newer soc working on existing hw first" that sounds like an anti-vendor port
<wolfspraul>
I don't believe in anti-vendor ports. I will continue to work on opening up the hardware we know best now, Ben NanoNote, make it easier to produce, simplify and open mechanical, etc.
<roh>
well.. there seems to be some work happening already.. i think its more 'learning to know and use a soc' than 'doing a anti-vendor port' (without their support)
<wolfspraul>
anti-vendor ports are lacking a foundation for the future, I rather work on the foundation
<roh>
isnt the ingenic documentation open for the new chips?
<wolfspraul>
sure that's good. lars has been doing 4760 related stuff in the kernel for over a year I think.
<wolfspraul>
not open
<wolfspraul>
or maybe Chinese way - under the table open
<roh>
well.. then it should be time to open it ;)
<roh>
when we now can get hw on the open market with that chip