<wolfspraul>
too bad that webirc guy is gone, I hope he can unbrick his Nano too...
<neil_>
I'll see if I can make a first attempt on updating that wiki page
<nebajoth>
woot neil_++
<freespace>
wolfspraul: i finally got a legible captcha, so account created :)
<wolfspraul>
argh
<wolfspraul>
I promised you math captcha yesterday
<wolfspraul>
:-)
<freespace>
you probably have more pressing issues :)
<wolfspraul>
I'm at -1 day now in terms of 'just in time delivery'
<wolfspraul>
no no, need to get this done
<wolfspraul>
lowering the barrier of entry for contributions is my #1
<wolfspraul>
it's the only chance we have to ever get this technology to a real user friendly level
<neil_>
it was pretty bad.  I had to try three times before I got lucky with one of the CAPTCHAs
<freespace>
nod
<wolfspraul>
nebajoth: neil_ maybe someone should contact the ubifs/mtd-utils/ubi-utils folks and point them to the NanoNote
<wolfspraul>
could be a quite interesting development device, with 2.6.34 running etc.
<wolfspraul>
I'm not sure what other devices they are mostly working with though, maybe others are even better...
<nebajoth>
I'll do it
<neil_>
doesn't hurt to let them know about the NN though
<wolfspraul>
or they are all Nokia guys and work on Nokia gear :-)
<nebajoth>
adding to my todo.txt on my NN
<wolfspraul>
I think I remember someone said Nokia donated ubifs to the free software world
<freespace>
the wiki is mediawiki yeah?
<neil_>
does the wiki support hierarchical pages like /wiki/Updating_Ben_NanoNote_software/Booting_from_SD ?
<freespace>
nvm, it is :)
<wolfspraul>
neil_: that beagleboard page pointed out earlier says to use flash_eraseall. I just tried it and it works. so that's better than giving the block count manually.
<freespace>
wolfspraul: you should import the mediawiki help pages
<neil_>
freespace: +1 to that idea
<wolfspraul>
how? can I give anyone admin or root access to help?
<freespace>
well, i can import them
<wolfspraul>
I love that mediawiki setup actually :-)
<neil_>
wolfspraul: ok, will put that in the wiki.  what's the command line?
<freespace>
by copy-pasta'ing the content from mediawiki
<wolfspraul>
freespace: let me first make your account an admin account, OK?
<freespace>
but that's like doing a manual walk of the entire help heirachy...
<wolfspraul>
maybe it helps you here and there
<wolfspraul>
neil_: the line is "flash_eraseall /dev/mtd1"
<freespace>
i figure there is a way for you to do it automagically
<freespace>
if there isn't, i will do it manually :)
<neil_>
wolfspraul: thanks
<wolfspraul>
freespace: whether you like it or not, I just turned you into an admin/bureaucrat in the wiki
<wolfspraul>
neil_: what is your wiki account name?
<neil_>
wolfspraul: unclouded
<freespace>
i am now part of the system i worked against?
<wolfspraul>
the accounts you mean?
<wolfspraul>
I work on easier anonymous edits next.
<wolfspraul>
neil_: also changed to admin/bureaucrat
<wolfspraul>
I am also very liberal with root access to the Qi server, for people who are able to and want to help with the Mediawiki server-side installation. but let's do step by step.
<wolfspraul>
urandom_: report them there, no problem
<wolfspraul>
you can just make one issue and add packages to it
<wolfspraul>
we have no hierarchy, so if everybody waits for someone to step up and introduce the great scheme by which everything is run, it will never happen
<wolfspraul>
instead, I think we should just start in different places. wiki forums, wiki pages, mailing list, indefero issue tracker
<wolfspraul>
then people can come forward and organize the mess :-)
<wolfspraul>
bottom up
<wolfspraul>
so just throw it in there
<wolfspraul>
I guarantee you all data on the Qi servers is dealt with carefully and will eventually be addressed
<wolfspraul>
only that the 'eventually' can be as far out as someone steps up to do it
<wolfspraul>
but if we don't even write up, the process cannot start
<wolfspraul>
urandom_: freespace some important links about the wiki/MediaWiki
<wolfspraul>
flash_eraseall /dev/mtd2 (should be 3)
<wolfspraul>
do you think you have to run flash_eraseall before ubiformat?
<wolfspraul>
I think in terms of the advice we give "least likely" etc. that's not very clear, but we have to start, so it's good
<neil_>
wolfspraul: no idea, sorry
<wolfspraul>
there is another way coming that will use xbboot to load an initramfs directly into ram and execute it there
<wolfspraul>
that avoids usbboot entirely and then we can even flash u-boot from inside a Linux kernel
<wolfspraul>
but anyway, this is a great start! thanks for writing it all up!
<wolfspraul>
maybe we can put the uImage into /boot/uImage right away in future releases (in .tar.gz). then we can simplify the steps in the documentation.
<wolfspraul>
very good start, thanks!
<wolfspraul>
this is your first day you have a Nano? amazing!
<neil_>
I would have been lost at sea without all the help I've had today, so thank you again.  my Nano would no still be bricked right now without everyone's help
<neil_>
s/no //
<mth>
larsc: in jz4740_clock_init, jz4740_clock_divided_clks members are accessed by fixed indices, but it seems that the indices are off (spi is actually at index 2 and i2s at index 1)
<larsc>
uh
<larsc>
grml
<larsc>
thanks
<mth>
larsc: I'm trying to make the cpufreq code behave itself better, but I think some bigger changes are needed to make that possible
<mth>
one thing is that desired frequencies are rounded to a possible divider value
<mth>
if the PLL freq changes, a new divider is needed
<mth>
but if every time the new divider is computed based on the rounded freq from the old divider, the frequency might end up at an undesired value after a lot of PLL freq changes
<mth>
so I think it's necessary to save the desired freq somewhere and always recompute the divider from the desired freq
<mth>
another thing is that the CPM spec says that for non-main clocks, the clock should be stopped while changing the divider
<mth>
but is it safe to just stop the clock at any point in time?
<mth>
it would not be safe if the device driver is doing things at the same time
<mth>
or even if the device is active but not inside the driver: for example a DMA transfer to the SLCD requires the pixel clock to be operational
<mth>
I don't know whether turning off the clock will simply stall the DMA transfer or cause data loss
<larsc>
well, but that would probably only be one frame
<mth>
not if we ever implement deferred I/O for the SLCD
<mth>
and if at some point we switch to DMA for MMC, even small data loss is a big problem
<mth>
also, I would like to try automatic cpu frequency scaling (based on system load)
<mth>
if that is operational, frequency switches would occur far more often than when only gmenu2x changes frequencies when launching something
<wolfspraul>
mth: since you seem to be another XBurst kernel hacker, are you interested in a 4760 EVB?
<wolfspraul>
that's the new CPU Ingenic is working on, should show up in devices next year
<mth>
wolfspraul: not right now: I've got a long enough TODO list for Dingoo at the moment
<mth>
it does sound interesting, so maybe later
<wolfspraul>
I don't have them available yet, but trying to understand whom I should ask beyond the guys I already know like Lars etc.
<mth>
I like kernel hacking, but I want to get Dingux in shape before moving to a next target
<wolfspraul>
mth: ok great, if you are interested let me know. indeed no rush on this, it's all moving forward.
<wolfspraul>
oh totally
<wolfspraul>
mth: do you have your own website somewhere? is this open-dingux?
<larsc>
mth: well there are notifier callbacks for frequency changes, so it's possible to do additional work in a device driver
<wolfspraul>
how do you build the distro? openwrt/oe/something else?
<mth>
CongoZombie is looking into using openwrt for the rootfs, but he got stuck trying to get the kernel headers from git
<larsc>
mth: so you would stop all transfers on an prechange event und resume them on a postchange
<mth>
larsc: is a prechange notifier also allowed to wait?
<larsc>
thats a good question. but i'll guess it has to
<larsc>
grepping through the kernel tree right now
<mth>
in the case of an SLCD transfer, it would be an option to abort it, but that might not be possible for all devices
<larsc>
for mmc it shouldn't matter if we disable the clock
<larsc>
the current transfer would pause
<mth>
don't registers become unreachable when the clock is off?
<larsc>
yes
<larsc>
but we should probably disable irqs anyway while changing the freqency
<mth>
but what if the driver is reading from the FIFO when the clock is turned off?
<larsc>
why should it do that?
<mth>
it will wait for the interrupt to get the next block of data, but if turning off the clock disables the FIFO reg, the last bytes of the previous block could be corrupted
<larsc>
hm, maybe you just found the reason for the mmc corruption on dingux kernels...
<mth>
you mean booboo's kernel can turn off the clock too early?
<larsc>
well, it is at least switching frequencies
<mth>
booboo's kernel uses userspace as the default governor
<mth>
so it won't switch frequencies at random moments in time
<larsc>
but gmenu2x does, right?
<mth>
yes, and it even bypasses the kernel completely when switching freqs
<mth>
that code is evil and I'll remove it soon
<larsc>
yes
<mth>
but booboo could reproduce the corruption from telnet without using gmenu2x
<larsc>
I'm wondering if we disable the dma clock. will it simply pause transfers?
<mth>
also, joyrider ported gmenu2x to Dingux in the beginning of 2010, before that only dmenu was used and dmenu does not mess with the CPU frequency
<mth>
maybe; if so things will be a lot easier if we use DMA for all transfers
<mth>
we'd still have to make sure device register writes and DMA setup only happens when the respective clocks are enabled though
<mth>
how long are timeouts on typical operations? if we disable a transfer for too long, it might also cause problems
<mth>
maybe not a problem if there is an automatic retry
<larsc>
what operations?
<mth>
for example, MMC reads/writes
<larsc>
you won't trigger those while chaging the freq
<mth>
with SLCD there is no timeout, since there is no transaction: every pixel written simply updates the current write position in the GRAM
<larsc>
the mmc timeout is currently set to 5 seconds
<mth>
ah, that won't be a problem indeed
<mth>
is it feasible to use EXT as the USB clock source?
<mth>
that would make it immune to PLL freq changes
<mth>
actually, what is the relation between the UHC clock and the UDC clock?
<mth>
hmm, ohci-jz4740.c does not have a copyright header
<mth>
ah, ohci-jz4740.c is never compiled
<larsc>
mth: thats all fixed in the upstream version
<calamarz>
enjoys w3m-image on the nn
<larsc>
uhc ist usb host udc ist usb device
<larsc>
mth: btw there is a flag to latch all clock divider changes
<mth>
I saw that, but it only applies to the main clocks, not to the others
<larsc>
hm
<larsc>
uhc needs 48Mhz
<mth>
eh, it does apply to all clocks, but still the spec says the non-main clocks should be stopped before changing freq
<mth>
it's UDC that can select EXT as a clock source
<mth>
I have no docs for UDC though, so I have no idea which clock ranges it can handle
<larsc>
well 12 Mhz is USB slow speed or whatever, right?
<larsc>
ok. slow is 3.5 Mhz, 12 is full
<mth>
it's called "full speed", but that means full speed for USB 1.0
<mth>
supplying it with 480 MHz is not feasible, I think, since the CPU might overheat at that point
<mth>
or can hi-speed work with speeds between 12 and 480 MHz as well?
<wejp>
it is not MHz but MBit
<larsc>
and with one bit per tick that becomes MHz
<mth>
or could it have a FIFO that has a separate clock for putting bits on the buts?
<wejp>
still the cpu does not needd to run at 480 MHz
<wejp>
yes
<wejp>
it not like the cpu is putting one bit per clock cylce through the usb interface
<mth>
does anyone have documentation of the UDC part?
<larsc>
yes
<larsc>
i'll send it to you when i'm home
<mth>
thanks
<larsc>
hm, the same udc core is used in some other uc for which the documentation is freely available on the net, but i don't remember its name :/
<mth>
my PC says the USB ethernet device is 480 mbit/s
<larsc>
but there is nothing in there about clocks :.
<mth>
larsc: that returns a data sheet for the SM502, but it looks very different from what the UDC driver is doing
<mth>
for example max packet size is written as-is to a 16-bit register by the UDC driver, while the SM502 PDF says it is stored in an 8-bit register where the maximum size is 8 times the value in the register
<larsc>
hm. ok. but it is at least very similar
<mth>
yes, but not for the purpose of figuring out what the device clock is used for exactly
<larsc>
right
<larsc>
given the fact that it is susposed to be able to run at high speed i would suspect that it has it's own pll for the bitclk
<larsc>
even the gmenu2x code did not adjust the udc clock
<larsc>
actually i can't find any code at all that touches the udc clock. not even usbboot
<larsc>
the default configuration is indeed to use the ext clk
<mth>
hmm, clock.c also selects ext clk
<mth>
for UHC the clock source is PLL, but not for UDC
<larsc>
right
<mth>
except if the boot loader selects PLL, since then jz4740_clock_init updates the clock parent
<mth>
so if we want to rely on the fact that the UDC clock source is EXT, it would be safer to set the clock source rather than adopt what the boot loader set, imo
<larsc>
imo we shouldn't mess with it
<larsc>
one problem i see is, that some drivers might want to roundup and some rounddown their clockfrequencies
<larsc>
for example the lcd driver would roundup while the mmc driver whould rounddown
<mth>
isn't that dealt with by having the round routine as one of the ops of the clock?
<larsc>
well, but if we wan't to adjust the clock speed when the ppl frequency is changed we don't know whether a driver rounded up or down
<mth>
imo the driver shouldn't round at all, the clock should do the rounding
<mth>
and save the value the driver originally requested
<mth>
ah, but that's not how it works right now
<larsc>
but the clock doesn't know whether it should round up or down
<mth>
can't it call it's own .round_rate op?
<larsc>
imo it is a layering violation to decide in which direction to round in the clock code
<mth>
an alternative would be to let the driver configure the rounding, but still have the clock perform it
<mth>
or could we require the driver set a new freq in the pre notification of the PLL change?
<larsc>
thats what other platforms do
<larsc>
some platforms implement a recalc callback for a clock
<qwebirc50625>
At the LinuxTag fair i owned a Nanonote
<qwebirc50625>
sb told me, the nano would automatically show up a ip number, wenn connected to ubunto (tcp/ip over usb)
<qwebirc50625>
what's that ip and where do i find a telnetd or sshd for my nano (i really prefer exporing it via keyboard and display of my notebook ... ;-)
<zear>
but with this wiki page you'll manage to set it up manually
<qwebirc50625>
tnx
<qwebirc50625>
i am looking for additional binaries for the default nanonote, e.g. bash (hate ash), sshd, a small cc, typical binaries, like expr, ... perhaps a webserver, lynx browser ..
<qwebirc50625>
where do i find just those binaries?
<zear>
once you set up the networking in your nanonote, run "opkg update"
<zear>
and then "opkg list | grep [your_app]"
<zear>
as for the url of the repo - no idea
<qwebirc50625>
oh wow! .... tnx lots
<qwebirc50625>
i really repreciate the original handbook of nano ;-)
<qwebirc50625>
depreciate ;-)
<zear>
i wish i had one :D
<zear>
but at the time i got mine (dev model) there was no printed manual yet
<qwebirc50625>
oh a belgium guy sold me one for 80¬ ;-)
<zear>
it's hard to put anything in the handbook if the device has almost no software at that point of time
<zear>
and anything can change
<qwebirc50625>
what i am also really missing is a app-place ... gnuchess, doom, tetris ... those games are already existing, but i had to find them up in the www via google ...bad!!!
<zear>
yeah, i guess that's what the repo is for
<zear>
but i haven't tried the opkg package repository yet
<qwebirc50625>
oh, missed that ... where can i find this repo via http:// ???
<zear>
honestly? no idea :D
<zear>
but check opkg configs
<zear>
there must be an address in there
<zear>
i don't know how much stuff is there anyway
<qwebirc50625>
ok, will find that ;-) but i am not always online ... at the moment i am mirroring every archive for nanonote onto my ubuntu ...
<nebajoth>
its awesome to do the same things on my NN as on my desktop
<nebajoth>
I run debian on mine, and its pure awesomeness
<jlmoko>
~seen tuxbrain
<zear>
nebajoth, really?
<zear>
like, what debian has to offer?
<zear>
besides cli, which is the same as everywhere
<zear>
i think desktop distributions ports have no real advantages on handheld devices like the nanonote
<qwebirc50625>
keyboard works correctly on ben nanonote with debian?
<qwebirc50625>
i really dislike qt and gtk+ is a memory pig ... so no real chance to install a gui on ben nanonote ...
<zear>
qwebirc50625, have you updated the firmware?
<zear>
the latest one comes with gmenu2x - a gui written in sdl
<zear>
it's really lightweight
<nebajoth>
zear: like I said
<qwebirc50625>
no, not yet ... original firmware ... why do you ask?
<nebajoth>
total transparency
<nebajoth>
the same set of tools as my desktkop user experience
<zear>
qwebirc50625, because the newest comes with gmenu2x
<nebajoth>
and a huge set of packages ready fo rinstallation
<zear>
so you can try it
<nebajoth>
for installation
<nebajoth>
it runs a treat, as long as you give it a little swap space
<nebajoth>
I see absolutely zero reasons to step down to a "custom" firmware
<nebajoth>
jlime is an interesting exploratory experiment
<nebajoth>
but I don't really see a use case for it except as some compromise between the openwrt spartan approach and the all-things-loaded debian one openwrt spartan
<mth>
the code is a mess though, so while it's useful to see what can be done, I wouldn't recommend copying its design into your own project
<zear>
;D
<mth>
qwebirc50625: wxWidgets on DirectFB is relatively light and can be themed
<qwebirc50625>
gmenu2x cpp ... better would have been c ... i really dislike any interpreters ... even dalvik .... memory pigs ...
<mth>
where is there an interpreter?
<qwebirc50625>
i have talked to nokia/siemens qt developers at the linuxtag fair ... qt is NOT FREE ...
<mth>
not free in what way?
<qwebirc50625>
cpp is a mixture between compiler and interpreter ... see e.g. virtual functions ...
<bartbes>
yes, elaborate, I want to know
<qwebirc50625>
commercial applications with closed source you have to pay for ...
<qwebirc50625>
commercial applications opensource is free
<mth>
that the difference between the GNU and BSD definition of free... nothing new there
<qwebirc50625>
talking about the new qt license
<bartbes>
yes commercial closed source is paid
<bartbes>
hmm weird
<bartbes>
well, not like I'm doing that anytime soon
<qwebirc50625>
this guy showed me the new touch libs for qt ... interesting ... but the license ... ;-(
<qwebirc50625>
and with new qt you can output javascript ... from the cpp source code ... but has its own JS interpreter weird ... but seems to work ...
<zear>
i see nothing wrong with paying for commercial use, but you should be obligated to release the source code anyway
<zear>
i just don't like any kind of closed source software
<zear>
paid or not
<qwebirc50625>
qt seems to have become all open source ...
<bartbes>
but I'm not quite sure when you need the commercial license
<bartbes>
they mostly say "if you can't comply with the LGPL"
<qwebirc50625>
commercial sold without source ... then u have to pay.
<qwebirc50625>
some sort of punishment ;-)
<mth>
if you link dynamically, LGPL even allows a closed source app to use a lib
<bartbes>
it's actually different
<bartbes>
I misinterpreted
<bartbes>
they say if it's commercial you need the commercial license, but you still have to comply with the LGPL
<qwebirc50625>
Hi Mirco!
<mth>
bartbes: that doesn't make sense
<qwebirc50625>
Mirco Lindner?
<bartbes>
mth: why?
<larsc>
qwebirc50625: he is not here
<qwebirc50625>
?
<mth>
because (L)GPL doesn't allow additional restrictions beyond what is in that license itself
<larsc>
qwebirc50625: mirko is a different mirko
<bartbes>
mth: it doesn't allow dual-licensing?
<larsc>
there are two of them...
<mth>
in the past, it was GPL or commercial; recently they changed that to LGPL or commercial
<larsc>
bartbes: it does
<mth>
bartbes: it does, but then the two licenses are completely separate
<larsc>
but you can put additional restrictions on the lgpl
<bartbes>
mth: I guess that is the case
<larsc>
can/can't
<qwebirc50625>
IMHO this ingenic board (built in in ben nanonote) has great future ... it's used everywhere in china ... not ARM they really prefer MIPS ... Software development in future comes from china ...
<qwebirc50625>
No chinese company will use qt ... ;-(
<qwebirc50625>
because of non free license ...
<bartbes>
hypocrite if you consider they steal everything themselves
<qwebirc50625>
where do i find information or code about powermanagement in ben nanonote?
<qwebirc50625>
chinese people always steal software themselves ;-)
<qwebirc50625>
ben nanonote has just usb client - not host? So i can't connect my hama stick to it?
<qwebirc50625>
That information right?
<zear>
qwebirc50625, unfortunally, that's true
<zear>
no usb host in ben nanonote
<qwebirc50625>
where can i get that SDIO with wifi card from?
<qwebirc50625>
usb host for usb clients would have been much better ... but tcp/ip over usb seem to work fine ;-) ... can connect hundreds of dedicated ben servers to one ubuntu machine ;-)
<sdschulze>
A platform with a hackable processor would be damn nice.
<sdschulze>
Is Milkymist OK as a multi-purpose platform?
<nebajoth>
sdschulze: doubt its very fast just yet
<nebajoth>
but it "runs linux"
<bartbes>
does it run crysis?
<nebajoth>
yep
<nebajoth>
at 1fps :D
<nebajoth>
-100fps
<nebajoth>
it starts at the end of the game
<nebajoth>
and moves backwards
<bartbes>
good answer to an otherwise horrible joke
<nebajoth>
its so slow
<nebajoth>
gotta roll with the punches!
<sdschulze>
nebajoth: oh, nice
<sdschulze>
my matter of interest: how do I make a processor more friendly towards type-safe programming languages?
<sdschulze>
probably a long-term issue, though
<sdschulze>
I would like my processor to help me doing array bound-checking, maybe garbage collection and maybe unboxing.
<qwebirc23620>
Hello. I tried re-flashing the NanoNote with Debian, according to the pyeno.org instructions on how to do so.. now, when I try to turn it on, it won't. Someone in here told me to put it into USB-boot mode... i've tried to do so for hours and hours, with no avail.. Is there any luck on unbricking my NanoNote?
<sdschulze>
qwebirc23620: So the reflashing was succesful?
<qwebirc23620>
Yes, it was. But someone told me that the boot-loader is corrupted.
<qwebirc23620>
Hence it not turning on.
<sdschulze>
Why would it be?!
<sdschulze>
Remove all power sources (battery and USB cable).
<qwebirc23620>
Well, someone in here, asked if the LED on the right side of the unit blinked really quickly upon power on, and it did.. so it was their opinion that the boot-loader was corrupted.
<sdschulze>
Then re-apply power by either inserting the battery or the cable.
<qwebirc23620>
I've already tried that.. many times.
<sdschulze>
Then re-re-flash...
<qwebirc23620>
I can't get it to into USB-boot mode...
<sdschulze>
not even using the hardware method?
<qwebirc23620>
Nope.
<sdschulze>
(the two pins)
<qwebirc23620>
I've tried tin foil, the little rubber deal that came with the NanoNote..
<qwebirc23620>
Yes. The two pins.
<sdschulze>
So you connected them and pressed the power button meanwhile?
<qwebirc23620>
Yes.
<sdschulze>
sounds like a hardware problem then...
<sdschulze>
maybe ask on the mailing list
<qwebirc23620>
Well, when recharging, the LED turns a bright red..
<sdschulze>
That's correct.
<qwebirc23620>
Yeah.
<sdschulze>
because it gets charged
<qwebirc23620>
Just saying that that may be a sign that the hardware is fine.
<sdschulze>
well, that it's not completely broken, rather
<qwebirc23620>
I'm just worried I brcked it.
<sdschulze>
How would you have done this?
<qwebirc23620>
Well, I am kind of assuming since the unit will not turn on.
<qwebirc23620>
And i've tried everything.
<sdschulze>
If you didn't open the case, you hardly have a chance to break anything.
<qwebirc23620>
Ah. Ok.
<sdschulze>
(AFAIK -- I've no real clue about the NanoNote hardware.)
<bartbes>
I always thought flashing was brick-sensitive
<qwebirc23620>
How does the "reset" button work? Any idea?
<sdschulze>
So your computer doesn't recognize the NanoNote as a USB device?
<qwebirc23620>
No, it doesn't.
<qwebirc23620>
# watch lsusb
<sdschulze>
bartbes: Dunno, but doesn't it just change the contents of the NAND flash?
<qwebirc23620>
I think i'm going to let it sit for a few hours... maybe that will help.
<qwebirc23620>
(With no battery or USB cable)
<bartbes>
think so, but if that memory gets corrupted your screwed, basically
<urandom_>
bartbes the ben is unbrickable cause it has hardware usb boot mode, you can always reflash
<bartbes>
urandom_: good to know
<sdschulze>
If you could break it that way, it wouldn't be recommended to do "nerase 0 4096 0 0".
<urandom_>
qwebirc23620 just retry till is works, you can always get into usb boot mode but it is sometimes hard to get into
<bartbes>
that sounds dangerous...
<qwebirc23620>
urandom_: Nod.
<sdschulze>
qwebirc23620: Try a different USB cable.  I've had experiences with bad USB cables...
<sdschulze>
though unlikely
<nebajoth>
you have to press damned hard
<qwebirc23620>
Ok.
<zear>
qwebirc23620, ah, so the nanonote won't boot?
<qwebirc23620>
zear: Nope.
<nebajoth>
and it was me who told you that it was likely a corrupt bootloader
<zear>
that's a VERY common problem when flashing using the script
<sdschulze>
qwebirc23620: I usually use a short wire.
<zear>
for me it's a 100% chance the script badly flashes the bootloader
<zear>
so i always flash the bootloader manually
<sdschulze>
qwebirc23620: Hold both ends in your hand like chopsticks.
<qwebirc23620>
I did it all manually. I even cut and pasted the commands into the shell.
<qwebirc23620>
Hmm.. I can't find a wire..
<sdschulze>
That way, it has worked best for me.
<qwebirc23620>
Maybe I can find a piece of speaker wire.
<bartbes>
you could always get some wire from your tv :P
<nebajoth>
I didn't have luck with wire
<sdschulze>
The ends should not be insulated, of course.
<nebajoth>
tinfoil is the only thing that worked for me
<bartbes>
what about a staple?
<sdschulze>
bartbes: similar to a wire
<sdschulze>
though you should remove the insulation
<bartbes>
yes, but it is an easy to obtain conductive material
<bartbes>
*object
<sdschulze>
(BTW, is "adding a USB boot button" on the TODO list?...)
<nebajoth>
haha
<nebajoth>
I'm doing it to mine
<nebajoth>
I got 28 AWG wire
<nebajoth>
going to break it out to the side of the case
<nebajoth>
put in a little switch
<nebajoth>
I was concerned it might displace the battery too much
<nebajoth>
but it fits fine
<nebajoth>
in fact, I've had a coiled piece in there for about 5 days
<nebajoth>
just sitting between the battery and the underside of the circuitboard
<nebajoth>
bbiab
<sdschulze>
Soldering -- if done well -- is of course the most reliable method.
<qwebirc87876>
Still no luck in getting it into USB-boot mode.
<zear>
qwebirc87876, a handy command: "watch lsusb"
<qwebirc87876>
I noticed a few people on a forum have the same problem as me.. no remedy, though.
<zear>
will tell you if the device is in usbmode
<qwebirc87876>
Yes. I used that command.
<zear>
and will save some time on typing the command
<qwebirc87876>
2 people say that they have the same problem as me.
<zear>
the bootloader is corrupted
<zear>
you have to reflash it
<zear>
that's the fix for it
<qwebirc87876>
I know. I know. But, I cannot boot into USB-boot mode.
<qwebirc87876>
I've been trying almost non stop since lastnight.
<zear>
qwebirc87876, maybe try with the aluminium foil
<zear>
roll it up and try to short both the pins
<qwebirc87876>
I tried that.. as well as a wire, and the carbon button that came with the unit..
<qwebirc87876>
I'll try again though.
<zear>
oh you have the button?
<zear>
then use that
<zear>
you just need to press it firmly
<qwebirc87876>
Yes. I've tried.
<nebajoth>
it is very odd
<nebajoth>
that you cannot start it in usb mode
<nebajoth>
have you tried scraping the surface of the contacts a little?
<nebajoth>
maybe there's some kind of residue preventing proper contact
<zear>
qwebirc87876, sometimes i had to try the button ~50 times to get it to boot
<nebajoth>
and crinkle the tinfoil
<zear>
but i think it's because i wan't pressing strong enough
<nebajoth>
yeah, you have to press insanely strongl
<nebajoth>
y
<nebajoth>
I'm breaking it out to a switch on the side of the unit as soon as I find a properly small switch :P
<qwebirc87876>
I'll try wiping the contacts off... wish I had some isopropyl..
<nebajoth>
zear
<nebajoth>
what firmware do you use?
<zear>
qwebirc87876, and just in case, that's how the pin shorting should look like: 1) press both the pins with the button AND hold it 2) still holding the button pressed, plug in the usb 3) don't release the button until the device is in usbboot mode (but if it doesn't happen after ~4sec, it failed and you have to try again)
<zear>
nebajoth, currently the newest
<zear>
i think
<nebajoth>
openwrt?
<nebajoth>
ok
<nebajoth>
does dumpkeys work for you?
<zear>
nebajoth, i think not
<zear>
but i don't remember right now
<zear>
but i tested it once
<zear>
the battery is dead, can't check it out now
<nebajoth>
k
<nebajoth>
how does openwrt determine keymap?
<zear>
no idea ;)
<nebajoth>
%)
<qwebirc87876>
Woohoo! Got it.
<zear>
qwebirc87876, ;D
<bartbes>
by cleaning the contacts?
<zear>
now, flash the bootloader manually
<zear>
not via the script
<qwebirc87876>
Nod.
<qwebirc87876>
Should I erase?
<qwebirc87876>
And re-flash everything?
<nebajoth>
yes
<nebajoth>
what did it, qwebirc87876?  cleaning the contacts?
<nebajoth>
or the order you did thing?
<nebajoth>
s?
<nebajoth>
wtf, keymaps are confusing
<qwebirc87876>
I'm not sure, exactly.
<qwebirc87876>
I think zear's instructions are what did it.
<nebajoth>
that actually makes sense
<qwebirc87876>
Thanks, zear.
<nebajoth>
I didn't think the contacts should be a real problem
<nebajoth>
it was just all I could think of
<qwebirc87876>
Anyone know where the Debian files to flash are localed?
<qwebirc87876>
I didn't care for OpenWRT.
<nebajoth>
the ubi is linked in the tuxbrain tutorial
<nebajoth>
that was linked above
<zear>
qwebirc87876, you're welcome ;)
<tuxbrain>
I will start to claim royalties for that tutorial :P
<zear>
:D
<zear>
btw tuxbrain, new console from GPH is in developement. What's your opinion on this? :D
<zear>
they showed it during E3
<nebajoth>
tuxbrain
<nebajoth>
my spanish amigo
<nebajoth>
do you know anything about keymaps?
<zear>
nebajoth, larsc should know
<zear>
larsc knows everything ;)
<tuxbrain>
man, not at all
<zear>
just don't bug him too often ;)
<nebajoth>
woop
<nebajoth>
larsc: ping
<tuxbrain>
zear:closed shit is closed shit in spite you paint it pink
<zear>
well, it's a wiz in a different case, with double ram ;)
<zear>
and with a faggy analog instead of a dpad
<tuxbrain>
well in this case black
<zear>
well, it's not *tat* closed, it runs linux
<zear>
there will be the full source code if it, as usual
<zear>
and a toolchain
<nebajoth>
half measures
<zear>
yea
<nebajoth>
impatient n00bs too eager to sacrifice freedom for an instant fix
<stuckie>
... they've had trouble getting the source code to the stuff on the Wiz out, and it took them ages to get a toolchain out too ;)
<zear>
stuckie, oh? I know it was the case with gp2x
<zear>
but i didn't know wiz wasn't open at first
<tuxbrain>
that the finally release the fonts of the all the libraries they use, including "his" version of sdl?
<nebajoth>
hahah I'm just trolling, in case anybody is associated with that project :D
<stuckie>
Wiz was slightly better.. they didn't take _quite_ as long
<nebajoth>
anybody here running debian and wants to run a dumpkeys for me?
<zear>
well, anyway i'm sticking to qi-hardware and dingoo
<tuxbrain>
well, doesn't mind, GPH on wiz was very loosy quality materials, I have lost a lot of interest in it
<stuckie>
I might grab a NanoNote at some point.. once I've exhausted all the crazy hacks I'm upto on the Pandora ( I'll then start doing crazy hacks on the NanoNote instead! )
<mth>
zear: double RAM, impopular case design and bad controls, it's just like the A330 :)
<wolfspraul>
bring it to cparty maybe carlos can rescue it :-)
<kristianpaul>
bur wait i'll see what can i do
<kristianpaul>
sure
<wolfspraul>
watch out with overheating
<wolfspraul>
then your ben may be totally broken
<wolfspraul>
also tp4 is close to the cpu I think
<kristianpaul>
avoiding that i think acidentally pull the cable and removed the pin
<kristianpaul>
yes it is
<wolfspraul>
the COB glue is spec'ed for a max of 150 celsius I think
<kristianpaul>
hmm
<kristianpaul>
damm
<wolfspraul>
if it becomes soft, the bonding wires inside may get damaged
<wolfspraul>
can you still boot the nano?
<kristianpaul>
wait
<wolfspraul>
if you only mechanically ripped off the TP, it usually can be rescued by finding the wire under the PCB coating and doing a little surgery there
<wolfspraul>
but you need to be somewhat skilled so you don't make things worse and worse
<wolfspraul>
I couldn't do it for sure :-)
<kristianpaul>
yeah i'm about that but first i'll check boot
<wolfspraul>
we can swap nanos, I give you mine and vice versa
<wolfspraul>
I don't need tp4
<kristianpaul>
you relly need how my nano looks after disambled and assenle again..
<wolfspraul>
cool
<kristianpaul>
wait wait ill plug usb
<wolfspraul>
I like used computers
<kristianpaul>
uff it boots
<wolfspraul>
he he
<wolfspraul>
good
<wolfspraul>
be careful soldering close to the COB glue
<wolfspraul>
solder fast
<kristianpaul>
now time to surgery
<wolfspraul>
COB is not heat tolerant at all
<kristianpaul>
i was thinking use a epoxy to paste the pcb poiny again..
<wolfspraul>
the COB step is done after SMT, basically a cold process
<wolfspraul>
wire bonding, then glue
<wolfspraul>
after that there is no more heating
<wolfspraul>
until you approach it with the tip of your iron, he he
<wolfspraul>
so you need to keep the heat really local to the TP4 area
<wolfspraul>
do you plan to help Milkymist development on your avnet board?
<kristianpaul>
i plan learn more about MM then help ;)
<wolfspraul>
great
<kristianpaul>
so my knowledge is undergrounded i think is the word
<kristianpaul>
plus i dint learn verilog just vhdl..
<kristianpaul>
but MM is fantastic to learn, so far the papers are easy to follow
<wolfspraul>
good
<wolfspraul>
we need to be careful to not create too many, ideally none, dependencies on proprietary Xilinx stuff
<wolfspraul>
this is very high on Sebastien's watch list so that's good
<wolfspraul>
but there are always a few things here and there that can be improved
<wolfspraul>
like this mail you may have just seen on the list talking about reflashing without the xilinx webpack
<wolfspraul>
or simulation (icarus verilog/gtkwave) without needing Xilinx binaries
<wolfspraul>
but anyway, just got your avnet :-)
<wolfspraul>
do you bring it to cparty?
<kristianpaul>
sure
<kristianpaul>
done
<kristianpaul>
now wait 10min
<kristianpaul>
i think for now xilinx stuff is just nedeed for sintesys
<kristianpaul>
verilog is promising but still missing feature i tested and reported the bug
<wolfspraul>
well there are many details here and there I think
<wolfspraul>
proprietary dependencies are lurking everywhere :-)
<kristianpaul>
bu developers well, they just dont want to help as we like
<wolfspraul>
what do you mean?
<wolfspraul>
bu developers well?
<kristianpaul>
s/bu/but
<kristianpaul>
verilog developers,
<wolfspraul>
why not?
<kristianpaul>
i sjut a thread about a missing feature
<wolfspraul>
I'm not worried we get there
<kristianpaul>
wait
<wolfspraul>
the Icarus Verilog guy I think is doing this project in his spare time for 10 years already
<wolfspraul>
amazing
<wolfspraul>
we have to pump some money into free technology, to accelerate it...