irclog2html for blob on 2002.06.18

05:59:55Russsits down in front of the amd32.c
06:15:59seletzmorning
06:28:21Sammyhi seletz
07:00:06seletzSammy: hi
07:00:34seletzSammy: have your kernel running?
07:04:14Sammyseletz: yeap , but not a little stuck at kernel combine with rootfs
07:04:58seletzSammy: what's the problem?
07:05:20seletzSammy: i have a cramfs+initrd howto, with example images.
07:07:47SammyI build by myself with jffs2 use uclibc but hang on at this line
07:07:49SammyFreeing init memory: 68K
07:09:03seletzhmm
07:09:03mmattenhi
07:09:14seletzSammy: no root fs mounted?
07:09:28seletzSammy: why do you want jffs anyway?
07:09:43seletzSammy: (jffs is __slow__)
07:10:00Sammyseletz: can r/w flash at development time
07:10:11seletzSammy: what exactly did you built with ulibc
07:10:23seletzs/boult/build/
07:10:27seletzargl
07:10:28seletz:)
07:11:09SammyI copy some rootfs stuff from tux use and build it by myself and then test it
07:11:13seletzSammy: have you seen your kernel booting with a ramdisk at last?
07:11:31Sammyseletz: which part ?
07:11:41Sammyaddress or ?
07:12:16seletzone moment phone
07:13:02Sammyseletz: this is also my problem too , jffs2 will stay at this few line a little time
07:13:04Sammyjffs2_scan_empty(): Empty block at 0x0001fffc ends at 0x00020000 (with 0xe0021985)! Marking dirty
07:13:05Sammyjffs2_scan_empty(): Empty block at 0x0005fffc ends at 0x00060000 (with 0xe0021985)! Marking dirty
07:13:06Sammyjffs2_scan_empty(): Empty block at 0x0009ffec ends at 0x000a0000 (with 0xe0011985)! Marking dirty
07:13:22Sammyis this what you say __show__ ?
07:14:01Sammybecause I saw that tux booting quite fast , and it's also use jffs2 at /
07:14:01seletzi meant slow
07:15:06Sammyo , not booting time ...
07:15:08RussSammy: what did that test program do
07:15:43Sammyfinish , at LCD it's show , but at serial port isn't
07:16:25Russok, so maybe you need to add a console=ttySA0,115200 or something
07:17:04SammyI try put it at / , /bin/ , /sbin/ it's all can run
07:17:24SammyRuss: you mean at kernel command line or /etc/inittab ?
07:17:24Russjust say init=/testprog and put it in /
07:17:27Russcommand line
07:17:40RussSammy: inittab is read by /sbin/init
07:18:24Sammyis testing ....................
07:20:34SammyRuss: that console=ttySA0,115200 it's already have isn't it ?
07:20:56RussI don't know, do you
07:21:07Sammyyeap
07:21:24SammyKernel command line: console=ttySA0,115200 console=tty1 root=/dev/mtdblock2
07:23:06Sammycompiler kernel......
07:23:58Sammyloading .... and build rootfs again ...
07:33:44SammyRuss: init=/testprog put testprog at / show up at LCD panel but don't show at terminal :(
07:33:59Russok
07:34:06Russyou have console=ttySA0,115200 console=tty1
07:34:12Russyou are a running program
07:34:21Russby reading that, where will you display your output
07:34:25Russon ttySA0, or tty12
07:34:26Russer
07:34:26Russtty1
07:34:44Sammyboth
07:35:46Sammybut normally is at ttySA0 ...
07:37:47Russno, just one
07:37:55Russuser programs output on just one
07:38:07Russand it ends up being whatever console you name last
07:40:09SammyRuss: so I must change this to console=tty1 console=ttySA0,115200 to show test program run at terminal right ?
07:40:54Russright
07:41:16SammyRuss: but at this time , it's almost make sure that kernel can read what I point at init = XXX
07:41:40Russdid you put spaces in there?
07:41:44Russit should be init=/prog
07:41:48Russnot init = /prog
07:43:01SammyRuss: sorry my fault in command line is init=/testprog with space
07:44:12SammyRuss: at now it's mean that kernel can read any directory at rootfs , so if I can change it back and test init=/sbin/init ?
07:44:27Russdidn't you want /linuxrc?
07:44:47Sammyyeap
07:45:09SammyRuss: or anything I need to make sure ?
07:45:44SammyRuss: or need to write some script to test /bin/sh ?
07:46:46Russyou can just do init=/bin/sh
07:46:49seletzcd /da
07:46:58Russda?
07:47:07Russoh right, your are german
07:47:08Russda
07:47:31Russeither that or you have erikm's cross compiler installed
07:47:51Sammywhat's da ?
07:48:16SammyI use erikm's cross compiler (2.95.3)
07:48:23Russthere
07:48:50Russbut he was probably getting set to do cd /data/cross/lart...
07:48:58Russbut then passed out due to lack of caffine
08:04:14seletzoh my
08:04:23seletzsorry, wrong window :}
08:05:04seletz(cd /data/dafit was it, /data if my CF on my dev board. doh.)
08:06:23seletzgetting coffee
08:32:14Sammyhowdy erikm :)
08:32:30erikmmorning, sammy
08:32:41SammyRuss: init=/bin/sh nothing happen :(
08:34:43Russerikm: have you read the amd flash doc?
08:35:02erikmRuss: no. I think I have it but I didn't read it
08:35:10seletzmoin erik
08:35:13Russits very different than the intel one
08:35:36erikmRuss: that's what I gathered when I rewrote the flash layer
08:36:32RussI think I'm going to switch the erase stuff to the toggle bit method
08:36:47Russwhile bit 2 is toggling, its erasing
08:37:04Russif bit 5 gets set to one while its toggling, then there is an error
08:37:33Russhowever, if you check again, after bit 5 was set, and its not toggling, it wasn't an error
08:42:31RussSammy_mad: if the test program runs, but busybox sh doesn't, then you know where the problem is
08:43:18Sammy_madRuss: is that linking problem ? or busybox's problem ?
08:43:28Sammy_madcheck
08:43:31Russeither
08:44:09seletzRuss: hmm. AMD flashes. Generally, do they work with BLOB ATM?
08:44:30seletzRuss: or isit Dont use them, use INTEL StrataFlashes
08:44:30Russseletz: there is a problem where if you flash more than one thing, without reseting
08:44:38seletzugh
08:44:43Russit gets stuck, and then blob gets overwriten
08:44:46seletzRuss: thats a real issue
08:44:48Russmy code, my problem
08:45:23seletzRuss: is the linux MTD layer capable of handling AMD flashes?
08:45:33Russya, it does great
08:45:39seletzphew
08:45:47Russamd flash is much easier to obtain than intel flash
08:46:02seletzdiscovered that just this morning :(
08:46:20seletzRuss: they're way cheaper too, as it looks.
08:46:22Russluckily, its easy to make a footprint that supports both
08:46:48Russon some of the larger flashes, address lines differ, but for a TSOP48, all you need is three 0 ohm jumpers
08:47:00seletzRuss: ah, cool.
08:47:27seletzRuss: then I'll stick to TSOP48 on my dew design
08:47:40seletzs/dew/new
08:47:47Russjust look at the respective pinouts
08:48:22seletzRuss: do you have some recent price quotes for StrogARMs?
08:48:27Russnope
08:49:00seletzRuss: hmm. My manufactorer mumbles something in the $38 range.
08:49:16seletzRuss: thats quite expensive IMHO
08:49:34RussI'd really like to switch to sa1110
08:49:41Russas well as bga flash and dram
08:49:43seletzRuss: INTEL germany refuses to quote SA1110 processors. They say "use XScale"
08:49:44Russer, sdram
08:49:54Russbut it'd be a time consuming redesign
08:50:00Russseletz: in what quantities
08:50:11RussI don't trust xscale yet
08:50:29seletzRuss: prototype quantities. And yes, i dont trustxscale too (as of now).
08:50:55seletzRuss: are you going to show up at OLS?
08:51:10RussI have no way of getting there
08:51:19seletzRuss: pity
08:51:27Russseletz: I can pass you on to triad, they are getting me sa1100's in quantities of 100
08:53:49seletzRuss: what's the price for sa1100 in 100pcs lots?
08:53:56Russdon't know
08:54:32seletzRuss: ok, would you please email me the contact infos of triad? or a URL?
09:04:02seletzbtw, why is it that inw() does use 2 byte accesses (PCMCIA mem range)? I have to use inline asm to get word acesses ...
09:07:27Russmaybe you nIOIS16 line is low?
09:07:33seletznope
09:07:57Russoh, ok, the inline asm works
09:07:59seletzyes, its lopw
09:08:24Russwhat if you use res = *(some (u16 *))?
09:08:30seletznopw
09:08:35seletzargl
09:08:39seletzno, does not work
09:08:48seletzi casted to unsigned short
09:08:55seletzdoesnt work.
09:09:32seletzthe only way it really works is when i use ldrh/strh
09:10:06Russwhat gcc?
09:10:29seletzeriks toolchain, one moment
09:10:47seletzgcc version 2.95.3 20010315 (release)
09:13:51Russmight ask erikm about that
09:13:57RussI'm not to wise in that area
09:14:03Russs/to/too/
09:14:06seletzi hunted down through the kernel headers just to get that inw() is evaluated to the same cast i used. So i thought of it as some gcc voodoo problem...
09:14:39seletzerikm: are you here?
09:14:41seletz:)
09:16:24erikmyes
09:16:47erikmgcc emits ldrh/strh instructions with -mcpu=strongarm1100
09:17:04seletzerikm: ugh
09:17:18seletzadjusts CFLAGS
09:17:18Russerikm: is that enabled in any kernels?
09:17:29erikmRuss: yes
09:17:35Russwhich ones?
09:17:37seletzbut not in modules i guess
09:17:54seletzmodules not in the kernel tree, that is
09:18:05erikmalso in modules
09:18:08erikmseletz: ok, then you have to do that yourself
09:18:18seletzthanks
09:18:22Russerikm: you should add a flash init, to make sure that the flash is in array mode
09:18:29Russin the case of chain booting
09:18:30erikmRuss: IIRC I submitted a patch for it around 2.3.99-pre8 or so
09:18:34erikmRuss: makes sense
09:19:09Russanyway, I've cleaned up the amd code quite a bit, I think I'll have to go to the CFI spec for sector locking
09:20:27seletztests
09:24:40FareGrrr!
09:24:55FareCould I go that far without being in SVC mode?
09:25:08seletzerikm: cool, works! even uses an effective adressing mode! Thank you!
09:25:32erikmseletz: *nod*. the blob intel16 flash driver uses the same trick
09:25:35Farewhen I load the zImage at 0xc0408000 , blob doesn't die
09:25:47Farebut then the kernel dies when it uncompresses at 0xc0008000
09:25:57FareI have the feeling something's rotten.
09:26:44erikmFare: write out the memory map. look at the size of the zImage. if 0xc0008000 + sizoef(zImage) > 0xc0408000 the kernel will crash
09:27:02Fareno, the sizeof is inferior
09:27:08Farethe kernel is not 4MB long
09:28:06Farebesides, if blob crashes when it loads the zImage at c0008000, it suggests that overwriting some data structures in the first MB will crash the machine
09:28:56Farewhich in turn suggests that either we're not really in SVC (but could we go that far?), or some system device is using (via DMA?) some memory-mapped device around this place
09:29:32erikmFare: did you read http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html
09:29:58Fareyup, I did
09:30:11Fareand I got it right.
09:30:30erikmFare: --> linux-arm-kernel mailing list
09:30:33Faresince the fb is at c0003000, I can *see* the kernel or zImage, when I load it as c0008000
09:30:51Sammy_madAmmm...... Russ
09:31:17Sammy_madRuss: I find out that's busybox's problem ...
09:31:33Russwhat was the problem?
09:31:40seletzuclib?
09:32:08Sammy_madcan't run ...
09:32:16seletzhmmm
09:32:19Sammy_madwith uclibc
09:32:56seletzSammy_mad: have you linked it statically? Or do you provide ulibc in /lib of your root fs?
09:33:48Sammy_madI linked it dynamic and need uclibc in /lib
09:34:01seletzhmmm
09:34:27seletzI _think_ init must be statically linked, but i'm not sure
09:34:34Russseletz: nope
09:34:39seletz:)
09:34:40seletzok
09:34:52seletzRuss: how does it work, then?
09:34:53Russyou just need to check that your binaries are looking for ld*.so in the right place
09:35:02seletzahh
09:35:11seletzok, cross-compiler problem
09:35:17seletzyup
09:35:29Sammy_madhow to test busybox for arm ?
09:36:01seletzstrings busybox | grep .so ? and look where the path points to? Russ?
09:36:24Sammy_madI download one with rz into my good tux and  run ldd busybox , it's show
09:36:25Sammy_mad# ldd busybox
09:36:26Sammy_madnot a dynamic executable
09:36:56seletzerm. maybe i'd better shut up ....
09:36:56seletz:(
09:36:59Russyou want arm-linux-ldd
09:37:07Russfile will also tell you
09:37:29RussI think he has busybox linked statically though
09:37:53Farenote that when I mapped the zImage to c0008000, and blanked the screen beforehand, it seems that a few words were written between c0003000 and c0008000, which is NOT normal, afaiu
09:38:08Sammy_madRuss: so I must use dynamic to run ?
09:38:34Fare(I can *see* those things going on)
09:39:29RussSammy_mad: no
09:40:35Sammy_maduh ? and I don't have arm-linux-ldd to run :(
09:41:00Russthen use file
09:41:02Russwhat does file say
09:41:57Sammy_madRuss: busybox: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, statically linked, stripped
09:42:12Russthat is statically linked
09:42:53Sammy_madbuild a dynamic one to test
09:50:08Russerikm: for the AMD flash to be protected/unprotected, 12V needs to be applied it seems
09:50:25seletzoh no
09:51:06erikmRuss: if you have a controllable switch for that you can put it in the flash driver
09:51:20seletzRuss: that would complicate designs a bit
09:51:29Russsome of the newer chips do it at vcc
09:51:57erikmRuss: or make separate functions enable_protect()/disable_protect(), just like flash_enable_vpp()
09:52:20Russoi
09:53:13Sammy_madRuss: why is the file always say static link ? even I do this DOSTATIC = false ?
09:56:52Farewhere do I set stack size?
09:57:15RussSammy_mad: maybe do a make clean
09:57:16Russthen make
10:00:53Sammy_madx2Russ: give me a knife
10:01:09Farewhat about putting an openbios forth in blob?
10:02:10seletzFare: yuck
10:02:25erikmFare: no way
10:02:35erikmFare: blob embraces the kiss principle
10:04:31RussSammy_madx2: its probably not that big of a problem
10:04:45Russmake sure you have the latest version of busybox and uclibc
10:04:58Russyou might try compiling busybox against libc statically
10:05:51Sammy_madx2ok , downloading the lastest version ..
10:06:28Russmake sure you remove your old uclibc install if you are doing a new one
10:08:25Sammy_madx2Russ: no , I only change the busybox part
10:09:14seletzSIGLUNCH
10:09:22Russok, the new amd flash driver flashed something big
10:09:46Farecall with more than one parameter seems buggy:
10:10:35FareI called mymemcpy with 3 parameters, and the call was parsed correctly (argv), but passed the 1st paramter thrice to mymemcpy!
10:11:32Sammy_now go eatting dinner to get more flash air for his head
10:13:09Fareindeed there's argv[2] for all params in call.c !
10:13:23Russsammy_ good plan
10:22:43Fareshortly after I write to the zone after the framebuffer, the computer hangs.
10:22:48Russhmmmm...is this normal?
10:22:55Russerasing at 0x00100000... scanning down... resume writing at 0x00100000
10:22:56Russerasing at 0x00120004... scanning down... resume writing at 0x00100000
10:22:56Russerasing at 0x00140004... scanning down... resume writing at 0x00100000
10:23:05Russshould it always resume at the same sector
10:26:02Russah dammit, I killed it
10:44:07Farenow it dies at Uncompressing Linux...............
11:08:56FareUncompressing Linux......................... // incomplete literal tree // -- System halted //
11:10:54Farewhat does that mean?
11:16:56erikmno idea, never had that. the source usually has comments around an error
11:25:30seletzhi again
11:29:09seletzFare: ugh. commands/call.c needs a review badly :(
11:30:20Fareseletz: I fixed the bug in my tree
11:30:46Fare(easy enough)
11:31:15seletz_grrr
11:31:20seletz_network hiccups
11:31:44Farebug detected by inflate.c
11:34:55Farecould it be that some DMA device writes stuff somewhere in memory?
12:01:16erikmFare: only the serial ports can DMA something into memory, the LCD controller only DMAs something out of the memory
12:03:31erikmRuss: it resumes writing at the point where it finds the first non-erased flash location
15:53:31prpplagueif you here a loud pop, its just my head exploding from my sinus headache
15:53:45prpplaguedon't be alarmed
15:56:01erikmloud noises come from outside over here. thunderstorm going on
17:02:14sammy_wmsprpplague: come from more beer?
17:04:44sammy_wmsbtw , if I had headache , sometimes all come from drunk :)
17:05:02Sammy_zzznight all
17:31:18Russerikm: I wish we would get rain
17:37:00erikmRuss: heh. the sky just becomes clear over here
18:23:19prpplagueerikm: nice thunderstorm? love the lighting of a good storm
18:37:27Farehum
18:37:35Faredoes the DMA explanation seem plausible?
18:37:49Farejust what could I be overwriting?
18:40:19Farewhat DMA devices exist in a SA1100/SA1101 ?
18:44:16erikmprpplague: this one wasn't as visible as I'd like it to be
18:44:34erikmFare: only the serial ports can DMA something *into* RAM
18:45:52Fareerikm: hum
18:46:02Farecould that be the case here?
18:46:46Farewhat about the pcmcia eth?
18:46:52erikmno dma
18:47:00Fareor the CF memory?
18:47:04erikmno dma
18:47:14Faregrumble.
18:47:20erikmCF memory == very dumb IDE
18:47:30Fareor the USB?
18:47:45Faretries to imagine what can go wrong
18:48:51erikmUSB is a serial port
18:49:04erikmjust disable all serial devices
18:49:23Farehow can I do that?
18:49:49erikmsee the SA1100 manual
18:49:59Fareis there code in blob for that?
18:50:03erikmno
18:50:19Farehum. ok. I'll see about it.
18:50:45Fareit seems very plausible to me that WinCE would map its devices in low memory
18:51:09Faremaybe by repeatedly md5'ing the memory, I could detect changes?
18:51:26Fareconsiders that a good method
18:53:46Fareanother tactic would be to leave whole stuff at that place, and have linux use the same statically-allocated buffers.
18:55:11Faresomething bugs me, though:
18:55:39Farewhy would it kill blob that some dma activity is going on at the place where it puts the kernel?
18:56:06Fareor would the dma device also read something like destination/length from that place?
18:56:52Farebtw, when I blanked the whole zone will 00's or with ea7a710e's it didn't crash
18:57:00erikmFare: you have to actively tell the DMA engine what to do next
18:57:14erikmFare: the DMA engines are interrupt driven
18:57:27erikmFare: and they don't do scatter-gather DMA
18:59:38Farehum. Then maybe accusing DMA is a wrong track.
19:00:14Faremaybe I'm just dumb and introducing bugs as I fix other ones :(
19:00:46FareI feel like I should develop a FORTH interpreter first
19:01:13Farebecause the compile-download-crash cycle is VERY long
19:01:26Farewhereas with some FORTH, I could debug on the fly
19:02:01Fare(guess why Mitch Bradley crushed single-handedly the swarm of C programmers who desperately tried to implement the Sun boot PROM)
19:09:02erikmFare: forth for an embedded bootloader is nonsense
19:09:14erikmFare: right now I can put a bootloader in 30k. try that with forth
19:22:53FareI can fit forth in 12k
19:23:05Faredid it in the past
19:23:25Fareand that was not a space-efficient forth implementation
19:24:05Fare(the 16-bit PC version was below 8k)
19:25:40Fareincluding the interactive "compiler".
19:33:02Farethe whole bootloader might end up being small in forth.
19:48:36erikmFare: a forth interpreter doesn't help you
19:48:57erikmFare: without a forth interpreter running in SVC mode the system still crashes
19:49:13erikmFare: besides, a forth interpreter is totally against the KISS principle
19:49:49Russ|werkwhat would the advantage of forth be, I'm confused
19:50:07erikmRuss|werk: do you know sun openprom?
19:50:52Russ|werkarghh...I think vtun is using something similar to if ((c = fgetc(fp)) != EOF) somewhere where c is a char
19:51:07Russ|werkerikm: ok, so the device have code on them
19:51:15erikmRuss|werk: *nod*
19:51:31erikmRuss|werk: would have made quite a lot of sense for PCI cards, btw
19:51:55erikmRuss|werk: so we wouldn't end up with PC and MAC variants of the same video card, etc.
19:52:46erikmRuss|werk: or the alpha way to get video working: emulate a 80x86 CPU just enough to be able to run the video BIOS
19:53:09Russ|werkI would think on a bootloader, you'd want a much simplier bytecode
19:53:29Russ|werkemulate a non-existant minimal micro
19:53:48erikmRuss|werk: forth is quite simple
19:54:16erikmRuss|werk: but I see no point in using it for an embedded device where the number of supported devices is quite limited
19:54:37erikmRuss|werk: and without the bootloader running in SVC mode it doesn't make any sense
19:57:05Russ|werkwith byte code, you could do it under 4k
19:57:33Russ|werkand write the original code in c
20:38:10Farethere are C->FORTH compilers
20:38:28Farethere are also bytecode VMs designed to fit on small smartcards
20:38:43Fare(no, not those braindead JVM variants - things like OTA)
20:38:58Farewith compilers from FORTH, C, Ada, etc.
20:40:38Russ|werkok, it was recording the return status of read with a register int
20:44:32Russ|werker...hmm

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with infobot logs, split per channel and by date, etc.