Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<wpwrak> hehe :)
<wpwrak> (build from source) i'll have to add some things for boom interaction anyway
<wpwrak> (upstream) don't you as the author of those patches want to do it yourself ?
<wolfspraul> I am overloaded
<wolfspraul> no news in ... months
<wolfspraul> plus I think my main work nowadays is simply to find money
<wolfspraul> as much as I like coding
<wolfspraul> can't do it
<wpwrak> i think the news concept has failed. at least the news-with-wolfgang-as-editor. pity. but maybe someone else will step up at some point in time.
<wpwrak> (find money) yes !! :)
<wolfspraul> we don't have many readers anyway
<wolfspraul> so the reason is more for archival purposes, and I do continue to connect those links
<wolfspraul> of course the intervals are not good
<wolfspraul> one by one
<wpwrak> (coding) with a little luck, upstreaming shouldn't be too dreadful. and probably easier to do it yourself than explain to xiangfu why exactly you've done what
<wolfspraul> possible, I will see
<wolfspraul> no worries we will try what works best
<wolfspraul> no dogma
<wolfspraul> but if xiangfu can help me, great
<wolfspraul> I don't want another up-leveling in 2013
<wolfspraul> I have no idea how 2011 disappeared so fast...
<wpwrak> ;-))
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #qi-hardware
* pabs3 wants an open hardware, firmware version of the Crypto Stick
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #qi-hardware
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
* kristianpaul Dormido
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
Jay7 [Jay7!jay@128-73-56-213.broadband.corbina.ru] has joined #qi-hardware
DocScrutinizer [DocScrutinizer!~halley@openmoko/engineers/joerg] has joined #qi-hardware
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
jekhor [jekhor!~jek@vulture2-nat-41.telecom.by] has joined #qi-hardware
stefan_schmidt [stefan_schmidt!~stefan@guest232.ibr.cs.tu-bs.de] has joined #qi-hardware
<wolfspraul> pabs3: are you saying the crypto stick is not open?
<pabs3> wolfspraul: not according to their intro page: "integrated (proprietary) smart card": http://www.crypto-stick.com/en/introduction
<wolfspraul> hmm, ok
<wolfspraul> need to find out more first
<wolfspraul> but I doubt it's proprietary because that's their business model
<viric> larsc: ah the patch... at the evening. I've that in my home computer
<pabs3> wolfspraul: if they're assembling off-the-shelf components (like that ATMEL or the uSD card), probably some of those are proprietary in some way: http://www.crypto-stick.com/2011/crypto-stick-2-beta-boards-arrived
<wolfspraul> sure, unless I see them actively closing up something somewhere, I'm not worried
<wolfspraul> and I think they are doing a serious and good project, but slowly we will learn more about it
DocScrutinizer [DocScrutinizer!~halley@openmoko/engineers/joerg] has joined #qi-hardware
Ayla [Ayla!~paul@87.169.26.93.rev.sfr.net] has joined #qi-hardware
<DocScrutinizer> stay tuned for c't testing the crypto-stick... ?
jekhor [jekhor!~jek@mx2.promwad.com] has joined #qi-hardware
<wolfspraul> DocScrutinizer: thanks a lot for helping out with the J3 audio expansion thing!
<DocScrutinizer51> yw
<wolfspraul> we start to polish the details a bit :-)
<DocScrutinizer51> I strongly prefer helping during design phase rather than later fixing hw bugs
<wolfspraul> well in that case it's just about reducing that big header to something more thoughtful
<wolfspraul> which I'm sure we now have, thanks to your help too
<DocScrutinizer51> and I'm regularly offering to do so, but alas often it gets ignored. So on GTA04-goldelico
<wolfspraul> well here I hope you recognize we appreciate your input a lot. worst case it's being recorded for the moment, and picked up later.
<wolfspraul> wiki, irc logs, etc.
<wolfspraul> gta04, don't know. I don't understand the project.
<DocScrutinizer51> don't worry, me neither :-D
<DocScrutinizer51> the 'funny' detail: again audio section is in top 3 of messed up circuits
<blogic> DocScrutinizer51: is audio out hard to layout ?
<blogic> i have a board here with i2c/pcm bus and wanted to make a small breakout with a wolfson codec on it
<blogic> i got the impression it would be trivial
<blogic> but reading your comments i might be mistaken
<DocScrutinizer51> nah, audio isn't particularly hard
<DocScrutinizer51> wolfspraul: (messed up) in GTA04
<DocScrutinizer51> wpwrak: I thought about the CD in a bit more
<DocScrutinizer51> the purpose of 'pulldowns' is obvious. But when you wnt that, you need pulldowns to virtual GND, not to real GND
<DocScrutinizer51> you may or may not want to tie virtGND to real gnd with a 100kR//1nF then
<DocScrutinizer51> bbl, work
<qi-bot> [commit] Wolfgang Spraul: Werner: we can drop the ERC pin exceptions patches. (master) http://qi-hw.com/p/eda-tools/78b197d
<qi-bot> [commit] Wolfgang Spraul: merged with cmdline patches (master) http://qi-hw.com/p/eda-tools/771599b
<qi-bot> [commit] Wolfgang Spraul: patch cleanup (master) http://qi-hw.com/p/eda-tools/724ca1e
antoniodariush [antoniodariush!~antonioda@nat-sta-smtc2.tvu.ac.uk] has joined #qi-hardware
<qi-bot> [commit] Wolfgang Spraul: updated patchset to kicad rev 3351 (current head) (master) http://qi-hw.com/p/eda-tools/0bdf904
<wolfspraul> wpwrak: you can try, I upticked it to 3351 (current latest)
<wolfspraul> actually there are so many renames going on they managed to break a few things in the last few days alone
<wolfspraul> active project, cannot complain. all the more reason to upstream asap.
<wolfspraul> I left out the pin collision patch for now because it's just a few lines, and of course that area changed as well. it's now called 'SynchronizePins()'
<wolfspraul> I could uplevel the patch, but that might do more harm than good because I would basically guess the meaning of those variables. better you look at it.
<roh> morning
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #qi-hardware
skynet-2000 [skynet-2000!~skynet-20@unaffiliated/skynet2000] has joined #qi-hardware
mirko [mirko!~mirko@simulachron-81.in-berlin.de] has joined #qi-hardware
viric [viric!~viric@unaffiliated/viric] has joined #qi-hardware
losinggeneration [losinggeneration!~quassel@71-34-161-176.desm.qwest.net] has joined #qi-hardware
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
<wolfspraul> morning
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #qi-hardware
<wolfspraul> wpwrak: looking at the m1 board a bit more thinking about the 'expansion system'
<wolfspraul> I think the corner around the audio and infrared makes a lot of sense, basically the entire 'upper floor' of that corner can be where the expansion boards can set
<wolfspraul> sit
<wolfspraul> the other side is crowded with large DMX connectors, video-in, jtag-serial, etc.
wolfspra1l [wolfspra1l!~wolfsprau@p5B0ADC9C.dip.t-dialin.net] has joined #qi-hardware
AwAyla [AwAyla!~paul@11.241.112.78.rev.sfr.net] has joined #qi-hardware
tonghuix [tonghuix!~tonghuix@123.115.192.73] has joined #qi-hardware
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
<wpwrak> wolfspra1l: (corner) yes. there's room there. no tall components, plus nothing on the case wall, so one can install a customized wall with openings, if needed
tonghuix [tonghuix!~tonghuix@123.115.192.73] has joined #qi-hardware
blogic [blogic!~blogic@nbd.name] has joined #qi-hardware
<cladamw> wpwrak, one quick question: we short L3 for fixing audio problem in rc3. When routing in rc4, just to use 0 ohm or directly short GND and AUDIO_AGND?
<cladamw> wpwrak, this question will be the same as L19 for video.
<cladamw> since there's different copper gnd(digital and analog) area splitted.
<cladamw> i think that I can just use copper wire to connect/wire two existed ground systems. (i.e. to be the same as rc3 patches now)
<cladamw> wpwrak, and keep the existing copper plates not to fill them up. or you have another different thinking?
<wpwrak> cladamw: (l3, l19) i'd short directly. l3 and l19 are clearly wrong and keeping them a "0 R" just adds confusion
<cladamw> oah~i typed in wrong channel
<cladamw> should go #milkymist
blogic [blogic!~blogic@openwrt/developer/blogic] has joined #qi-hardware
<wpwrak> wolfspra1l: (pin collision patch) okay, that one can wait a few days. we only need it when editing symbols.
<wpwrak> wolfspra1l: (things broken in the last few days) that sounds scary. what sort of breakage ?
<wolfspra1l> just renaming again
<wolfspra1l> they seem to love renaming
<wolfspra1l> I already mentioned it here, case up and down, underscore in and out
<wolfspra1l> no consistency either, seems several authors editing each others codes back and forth
<wolfspra1l> well then
<wolfspra1l> renaming all dialog classes from DIALOG_SOMETHING_BASE to DIALOG_SOMETHING_base begs for another rename :-)
<wolfspra1l> mixed-case - bah
<wpwrak> at least they're keeping the indentation/whitespace style, aren't they ? it's one of the ugliest i've ever seen, so it's hard to progress from the status quo
urandom__ [urandom__!~user@ip-88-152-208-231.unitymediagroup.de] has joined #qi-hardware
<wolfspra1l> wpwrak: yes I mostly see battles around underscores and case
<wolfspra1l> I replied to my 1-yr old thread on the mailing list :-)
<wolfspra1l> not very nice, but what's a good mail client for...
<wolfspra1l> at least it wasn't a 10-yr old thread
<wpwrak> let's hope people see it. if using a threading MUA, they may not notice
wolfspraul [wolfspraul!~wolfsprau@p5B0ADC9C.dip.t-dialin.net] has joined #qi-hardware
jow_laptop [jow_laptop!~jow@ffx.subsignal.org] has joined #qi-hardware
Textmode [Textmode!~boneidle@adsl-syd-2-209.ozonline.com.au] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
emeb [emeb!~ericb@ip72-223-81-94.ph.ph.cox.net] has joined #qi-hardware
rzk [rzk!~rzk@95-25-162-206.broadband.corbina.ru] has joined #qi-hardware
stefan_schmidt [stefan_schmidt!~stefan@p4FC77376.dip.t-dialin.net] has joined #qi-hardware
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #qi-hardware
kristoffer_ [kristoffer_!~kristoffe@c-e9d8e555.010-30-6c6b7012.cust.bredbandsbolaget.se] has joined #qi-hardware
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #qi-hardware
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #qi-hardware
<viric> I sent the patch
<viric> then, why my serial line does not work.grr
stefan__ [stefan__!~stefan@p4FC75CC9.dip.t-dialin.net] has joined #qi-hardware
<viric> now the serial works. weird.
<viric> but it fails sometimes at 57600
<viric> how reliable it should be?
<larsc> 100%
<viric> hm I send 'hello\n' in a loop...
<viric> and not all reach fine the other side :)
<larsc> hm
<viric> maybe it's me with stty, that I don't know how to use it.
<larsc> maybe your other side is broken
<viric> maybe I have too bad contacts :)
<larsc> since there is no flow control the jz4740 will happily send out new bytes whether the other side is ready to receive them or not
<viric> hm
<viric> not at all?
<viric> isn't xon/xoff working? I used "ixon ixoff" in both sides
<larsc> hm
<larsc> no hardware flow control
<viric> I know..
<larsc> sw flow control should work
<viric> (serial lines, 2012, and still a mistery to get right)
FrankBlues [FrankBlues!~alex@c-67-182-230-190.hsd1.ut.comcast.net] has joined #qi-hardware
<Ayla> if you have only 3 wires, then there's no hardware flow control
<viric> why shouldn't xon/xoff work? it's the OS implementing that, or the uart?
<larsc> probably a bit of both
<viric> through irqs..
<viric> maybe.
<larsc> but we use the generic 8250 driver
<viric> ok
<viric> uhm loading the driver reprograms the line at 57600 I imagine. Because at 9600, I see until the 'serial8250.0' loading :)
<viric> [ 0.800000] jz4740-nand jz4740-nand.0: No NAND chips found
<viric> I have MTD_NAND_JZ4740 enabled...
* larsc blames mth
<mth> NAND still works fine on the A320 though, I tested that
<viric> ehem. this kernel is not in its best moment ;)
<viric> Time for kgdb then! :)
<viric> what makes the nanonote sometimes turn on at connecting power, sometimes not?
<viric> btw, why can't I enable CONFIG_FRAME_POINTER?
<viric> maybe they are not required.
Ayla [Ayla!~paul@11.241.112.78.rev.sfr.net] has joined #qi-hardware
<larsc> viric: thanks for sending the patch
<viric> I was only the typing hand
<viric> I'm going to play with the uart...
<viric> I want the kernel to disable the gpio function of the pin, and use rx...
<DocScrutinizer> (xon/xoff) might work suboptimal when TX FIFO isn't handled in a way to place XOFF on top of FIFO, so another 16 or even 64 chars get sent until XOFF gets sent
<DocScrutinizer> larsc should know how that's inplemented
<viric> DocScrutinizer: so the uart has to help in that
<DocScrutinizer> I do't think UART knows XON/XOFF flow control
<viric> ah. then?
<DocScrutinizer> driver side implementation
<DocScrutinizer> I guess
<viric> maybe the driver can be set some chars to bypass the bufefr
<DocScrutinizer> the buffer is HW though
<DocScrutinizer> FIFO
<viric> I know
<DocScrutinizer> in UART
<viric> but maybe the uart can trigger an irq, if some special char 'enters' the fifo
<DocScrutinizer> that had to be checked
<viric> or maybe xon/xoff can't replace properly hw flow control
<DocScrutinizer> theoretically it's possible
<viric> but I think that proper UARTs should be able to use it
<viric> (with proper drivers)
<DocScrutinizer> proper driver: RX congestion -> flush TX FIFO, send XOFF, resend flushed bytes
<viric> you should handle the possible deadlock :)
<DocScrutinizer> even ignore TX-XOFF state, as XOFF may be sent even when TX is itself blocked by a XOFF
<DocScrutinizer> hehe ^^^
<viric> I don't find that easy to think about :)
<DocScrutinizer> XOFF/XON alway may get sent
<DocScrutinizer> always*
<DocScrutinizer> IOW, a XOFF may not prevent XOFF/XON to get sent
<viric> aha.
<viric> I agree
<viric> do you have the jz4740pm.pdf somewhere?
<DocScrutinizer> me? nope
<viric> anyone here
<viric> is it secret? :)
Ayla [Ayla!~paul@11.241.112.78.rev.sfr.net] has joined #qi-hardware
<DocScrutinizer> http://read.pudn.com/downloads160/ebook/723804/Jz4740-spec/Jz4740_ds.pdf hmm, not really good but doesn't mention XOFF IRQ
<viric> ok ok
* DocScrutinizer is feeling nostalgic about times when Zilog shipped their Z80 CPU with a proper paperback 150p manual
jekhor [jekhor!~jek@vulture2-nat-41.telecom.by] has joined #qi-hardware
<kristianpaul> paperback manual, nice ! i remenber when i used to print datasheets for PICs ;)
<larsc> never ever used printed datasheets
<kristianpaul> pic18f havent chnaged too much since 3 years i remenber.. i hope ;)
<kristianpaul> larsc: yes sure, for that time i dint have laptop and read on CRT display wasnt very nice..
<larsc> ah, ok
<larsc> as DocScrutinizer said, back in the good old days hardware come with printed manuals
<kristianpaul> i always wanted to have a z80... sigh
<larsc> kristianpaul: implement a z80 on the milkymist ;)
<kristianpaul> hahah
<kristianpaul> you serious?
<larsc> sure, why not
<larsc> the z80 is rather simple
<larsc> iirc
<kristianpaul> i agree with lekernel on this :) waste of time (:
<kristianpaul> hmm indeed
<kristianpaul> where are the multiplers ! :)
<mth> larsc: there is an open Z80 core for FPGA already
<larsc> mth: yea, though so
<mth> it's used in this system: http://www.hat.hi-ho.ne.jp/tujikawa/esepld/
<viric> mth: you introduced lots of changes in the nand driver :)
<mth> yes, but most of them only affect the behavior after the chips have been detected
<viric> hm ah
<mth> you can ignore the cc_ftl and A320 patches, they don't apply to NanoNote at all
<mth> e7ca5a665877a030c461959c0853e65a346de2de (multi-bank) does change the detection
<mth> hmm, "banks = " is missing from board-qi_lb60.c
<mth> can you try adding ".banks = { 1, 2, 3, 4 }," to qi_lb60_nand_pdata?
<mth> is there any variation in the NAND banks of different NanoNotes or is it always the same bank?
<viric> ok
<viric> I'll try
<viric> mth: worked
<mth> ok, then larsc was right to blame me ;)
<mth> larsc: should I make it search all 4 banks or should I hardcode the actual bank for the NanoNote?
<larsc> hm, i think hardcoding ist ok
<larsc> is
<mth> viric: in which bank was the NAND found? (see dmesg)
<viric> [ 0.830000] jz4740-nand jz4740-nand.0: Found chip 0 on bank 1
<viric> nothing on 2,3,4
<mth> ok, thanks
<viric> there was in the code: ret = nand_scan_ident(mtd, 1, NULL);
<viric> '1' is the bank, maybe.
<viric> no idea.
<viric> ah, 1 is 'maxchips'.
<DocScrutinizer> A nice reading matter: http://www.zilog.com/docs/z80/um0080.pdf p.42ff >>... When an EI instruction is executed, any pending interrupt request is not accepted until after the instruction following EI is executed. This single instruction delay is necessary when the next instruction is a return instruction. Interrupts are not allowed until a return is completed. The... << - I think I learnt all I know about IRQ from Zilog Z80 UM :-D
<viric> mth: should I wait for a commit?
<qi-bot> [commit] Maarten ter Huurne: MIPS: JZ4740: qi_lb60: Look for NAND chip in bank 1. (jz-3.2) http://qi-hw.com/p/qi-kernel/450999b
<viric> oh ok nice
<mth> that's a yes :)
* wpwrak remembers going to the intel office in zuerich at the age of twelve or so, trying to buy 8080 documentation. they were a bit puzzled but kind enough let me have the manual for free. i still have it. one fun fact is that it mention even the 8088. remarkable long-term planning. needless to say, that was a few years before downloadable pdfs :)
<DocScrutinizer> :-D http://www.zilog.com/docs/z80/ps0178.pdf <- scanned from my original ;-)
<DocScrutinizer> wpwrak: I conclude you are some ~7 years younger than me
<DocScrutinizer> maybe 5
<kristianpaul> lol
<wpwrak> ;-)
<viric> larsc: I could attach a gdb at boot :) but I forgot the debug symbols
<wpwrak> 1967 here
<viric> but 'cont' made the kernel boot :)
<viric> larsc: I wrote jz_gpio_set_function(JZ_GPIO_UART0_RXD, JZ_GPIO_FUNC_UART0_RXD); in the 'board_gpio_setup' as a trick to have rx working on ttyS0
<larsc> :)
<viric> fair? I had no idea what todo
<viric> nicer would be a kernel cmdline parameter for that
<larsc> looks good
<viric> but who knows how to write that
<larsc> pretty easy
<larsc> there is one for the avt2
<larsc> you could use that as a skeleton
<viric> what is an avt2?
<larsc> it was a experimental nanonote board with usbhost and 64MB ram
<viric> not jz4740?
<larsc> jz4740
<larsc> instead of the jz4725
<viric> there is only jz4740 and a320, not?
<larsc> hm?
<viric> I'll recheck
<larsc> in the nanonote board file there is a callback which registers the usb host device
<larsc> called avt2_something
<larsc> or something_avt2
<viric> ah yes
<viric> jz4740-ohci?
<viric> there are cmdline checks in that driver?
<larsc> no in the nanonote board file
<viric> hm
<larsc> just search for the function name
<viric> I couldn't see them then
<viric> I think I did
<larsc> let me check
<larsc> board_avt2 is the function
<larsc> and it is hooked up to the avt2 keyword on the commandline via __setup("avt2", board_avt2);
<viric> ahh
<viric> I had no idea that was a hook
<DocScrutinizer51> wpwrak: so my initial guess was absolutely correct :-) tell me which CPU you used and I tell you how old you are
<wpwrak> ;-)
<Ayla> DocScrutinizer51: Pentium 3
<Ayla> ?
<larsc> DocScrutinizer51: my first cpu was a pentium I 90 Mhz
<Ayla> how old am I? :D
<Ayla> logically, I'm a lot younger than larsc
<DocScrutinizer51> too young :-D
<larsc> and my first "compiler" visual studio c++ 6.0
<wpwrak> eek
<larsc> hehe :)
<wpwrak> glad you managed to become a decent person despite the abuse you suffered in your youth :)
<wpwrak> or maybe it was that what instilled a strong willingness to escape the misery
<viric> hm I don't manage to debug with kgdb.
* nbd started with a cyrix 486 DX and turbo pascal ;)
<Jay7> turbo pascal is the best!
* Jay7 started from P1 100Mhz w/o MMX
<Jay7> 16Mb RAM btw..
* wpwrak wonders if psychoanalysts ask hackers about their first cpu and compiler. these two are probably a lot more influential on the shape of the blossoming mind than, say, parents
<Jay7> but before was ZX Spectrum :)
<Ayla> actually I started with a 6MHz Z80 CPU
<Ayla> and 32kB of RAM
<wpwrak> Ti 57, 50 program steps, 8 data registers
<viric> it looks like the vmlinux addresses don't match those of runtime at the nanoonte
<larsc> wpwrak: and my first book on programming book 'c++ in 30 days'
<Jay7> larsc: I have that book :)
<viric> hm
<Jay7> or may be similar at least
<viric> larsc: the kernel is not loaded at the addresses the vmlinux elf says
<larsc> by whom?
<viric> by my xbboot command
<larsc> viric: the load address or the entry point address is wrong?
<viric> hm I don't know
<viric> when I attach gdb, it sayas:
<viric> syas
<viric> says
<viric> #0 0x81c5274f in ?? ()
<viric> while 'info file', says:
<viric> 0x80010000 - 0x803210c8 is .text
<larsc> is the kernel halted when you attach gdb?
<viric> I used the vmlinuz load address calculation, and uploading to that... it boots fine too, but gives the same gdb symbol strouble
<viric> larsc: yes yes. if I write 'cont', it continues
<viric> But why is it at 0x81c5274f, I don't know
<larsc> viric: have you tried break some_kernel_symbol? The address you see above is probably just some userspace process
<viric> I tried
<viric> larsc: I use 'kgdbwait'. it's halted just after the serial driver got loaded.
<viric> (no user space)
<larsc> ah, ok
<viric> 'disasm' fails
<viric> I mean, that 'disasm symbol' does not disassemble the symbol
<viric> :)
<larsc> hm
<viric> I think the bad boot messages mean: uncompressing kernel at address 80010000
<viric> (there are some characters 'eaten' there... the early console may be working bad)
<viric> 80010000 is the vmlinux load address.
<viric> hm I see the vmlinuz address is not very important.
<viric> it has to be valid, and it shouldn't be overwritten by decompression :)
<viric> larsc: using kdb, it looks fine.
<viric> with gdb, bad.
<viric> oh
<viric> I forgot to start the *mipsel* gdb.
<DocScrutinizer> wpwrak: EEEEK TI
<viric> stupid me
<viric> it works perfect
<DocScrutinizer> HP-25 here
<viric> kgdb working!
<DocScrutinizer> wpwrak: and we coded everything from "shortest fastest prime factoring" over "mastermind" and "guess the atom"(send ray in a grid, see where it exits), to auto-adjusting converters for Philips cassette tape counter to real playtime (sub minute accuracy) and even stopwatches (a pity on that "platform", we learnt a lot though about how the CPU works :-D)
<DocScrutinizer> e.g. execution speed for a particular instruction was a sawtooth function vs the location in "RAM" of that instruction
<DocScrutinizer> and of course the whole thing was highly ambient temperature susceptible
<DocScrutinizer> and the best time to compete on all those nice efforts was during english and physics lessons ;-D
<wpwrak> i mainly wrote games in my early years :)
<viric> larsc: so, enough for today. Victory!
<larsc> nice
<Ayla> I see that you define the root filesystem as being UBI
<Ayla> and I remember the nanonote uses UBI too (IIRC)
<viric> Ayla: well, that's what I have in the nand
<Ayla> how do you guys boot to UBI? I thought u-boot didn't support it
<viric> the kernel is in a nand partition directly
<viric> not in a file
<Ayla> ah, ok
<viric> there are 4MiB for it.
<viric> although uboot loaded only 2MiB (cough)
<Ayla> I started a new bootloader for JZ-based devices,
<viric> ah
<viric> how so?
<Ayla> it's called UBIBoot because it boots to UBI
<viric> to a file in an ubifs?
<Ayla> no, to a kernel flashed on a UBI volume
<viric> ah
<viric> why not implement that on uboot?
<Ayla> well, I wanted to create a bootloader myself :)
<viric> ah ok
<Ayla> back on topic - good job with kgbd
<viric> I like when people write on the documents what they type and also what they see as result :)
<viric> I remembe as if the qihw wiki had too much of 'type that', without result
<viric> ok, sleep.
<viric> Goedenacht
<DocScrutinizer> now uBoot bashing continues *here* ? :-S
zrafa [zrafa!~rafa@186.137.0.13] has joined #qi-hardware