| 05:59:55 | Russ | sits down in front of the amd32.c |
| 06:15:59 | seletz | morning |
| 06:28:21 | Sammy | hi seletz |
| 07:00:06 | seletz | Sammy: hi |
| 07:00:34 | seletz | Sammy: have your kernel running? |
| 07:04:14 | Sammy | seletz: yeap , but not a little stuck at kernel combine with rootfs |
| 07:04:58 | seletz | Sammy: what's the problem? |
| 07:05:20 | seletz | Sammy: i have a cramfs+initrd howto, with example images. |
| 07:07:47 | Sammy | I build by myself with jffs2 use uclibc but hang on at this line |
| 07:07:49 | Sammy | Freeing init memory: 68K |
| 07:09:03 | seletz | hmm |
| 07:09:03 | mmatten | hi |
| 07:09:14 | seletz | Sammy: no root fs mounted? |
| 07:09:28 | seletz | Sammy: why do you want jffs anyway? |
| 07:09:43 | seletz | Sammy: (jffs is __slow__) |
| 07:10:00 | Sammy | seletz: can r/w flash at development time |
| 07:10:11 | seletz | Sammy: what exactly did you built with ulibc |
| 07:10:23 | seletz | s/boult/build/ |
| 07:10:27 | seletz | argl |
| 07:10:28 | seletz | :) |
| 07:11:09 | Sammy | I copy some rootfs stuff from tux use and build it by myself and then test it |
| 07:11:13 | seletz | Sammy: have you seen your kernel booting with a ramdisk at last? |
| 07:11:31 | Sammy | seletz: which part ? |
| 07:11:41 | Sammy | address or ? |
| 07:12:16 | seletz | one moment phone |
| 07:13:02 | Sammy | seletz: this is also my problem too , jffs2 will stay at this few line a little time |
| 07:13:04 | Sammy | jffs2_scan_empty(): Empty block at 0x0001fffc ends at 0x00020000 (with 0xe0021985)! Marking dirty |
| 07:13:05 | Sammy | jffs2_scan_empty(): Empty block at 0x0005fffc ends at 0x00060000 (with 0xe0021985)! Marking dirty |
| 07:13:06 | Sammy | jffs2_scan_empty(): Empty block at 0x0009ffec ends at 0x000a0000 (with 0xe0011985)! Marking dirty |
| 07:13:22 | Sammy | is this what you say __show__ ? |
| 07:14:01 | Sammy | because I saw that tux booting quite fast , and it's also use jffs2 at / |
| 07:14:01 | seletz | i meant slow |
| 07:15:06 | Sammy | o , not booting time ... |
| 07:15:08 | Russ | Sammy: what did that test program do |
| 07:15:43 | Sammy | finish , at LCD it's show , but at serial port isn't |
| 07:16:25 | Russ | ok, so maybe you need to add a console=ttySA0,115200 or something |
| 07:17:04 | Sammy | I try put it at / , /bin/ , /sbin/ it's all can run |
| 07:17:24 | Sammy | Russ: you mean at kernel command line or /etc/inittab ? |
| 07:17:24 | Russ | just say init=/testprog and put it in / |
| 07:17:27 | Russ | command line |
| 07:17:40 | Russ | Sammy: inittab is read by /sbin/init |
| 07:18:24 | Sammy | is testing .................... |
| 07:20:34 | Sammy | Russ: that console=ttySA0,115200 it's already have isn't it ? |
| 07:20:56 | Russ | I don't know, do you |
| 07:21:07 | Sammy | yeap |
| 07:21:24 | Sammy | Kernel command line: console=ttySA0,115200 console=tty1 root=/dev/mtdblock2 |
| 07:23:06 | Sammy | compiler kernel...... |
| 07:23:58 | Sammy | loading .... and build rootfs again ... |
| 07:33:44 | Sammy | Russ: init=/testprog put testprog at / show up at LCD panel but don't show at terminal :( |
| 07:33:59 | Russ | ok |
| 07:34:06 | Russ | you have console=ttySA0,115200 console=tty1 |
| 07:34:12 | Russ | you are a running program |
| 07:34:21 | Russ | by reading that, where will you display your output |
| 07:34:25 | Russ | on ttySA0, or tty12 |
| 07:34:26 | Russ | er |
| 07:34:26 | Russ | tty1 |
| 07:34:44 | Sammy | both |
| 07:35:46 | Sammy | but normally is at ttySA0 ... |
| 07:37:47 | Russ | no, just one |
| 07:37:55 | Russ | user programs output on just one |
| 07:38:07 | Russ | and it ends up being whatever console you name last |
| 07:40:09 | Sammy | Russ: so I must change this to console=tty1 console=ttySA0,115200 to show test program run at terminal right ? |
| 07:40:54 | Russ | right |
| 07:41:16 | Sammy | Russ: but at this time , it's almost make sure that kernel can read what I point at init = XXX |
| 07:41:40 | Russ | did you put spaces in there? |
| 07:41:44 | Russ | it should be init=/prog |
| 07:41:48 | Russ | not init = /prog |
| 07:43:01 | Sammy | Russ: sorry my fault in command line is init=/testprog with space |
| 07:44:12 | Sammy | Russ: 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:27 | Russ | didn't you want /linuxrc? |
| 07:44:47 | Sammy | yeap |
| 07:45:09 | Sammy | Russ: or anything I need to make sure ? |
| 07:45:44 | Sammy | Russ: or need to write some script to test /bin/sh ? |
| 07:46:46 | Russ | you can just do init=/bin/sh |
| 07:46:49 | seletz | cd /da |
| 07:46:58 | Russ | da? |
| 07:47:07 | Russ | oh right, your are german |
| 07:47:08 | Russ | da |
| 07:47:31 | Russ | either that or you have erikm's cross compiler installed |
| 07:47:51 | Sammy | what's da ? |
| 07:48:16 | Sammy | I use erikm's cross compiler (2.95.3) |
| 07:48:23 | Russ | there |
| 07:48:50 | Russ | but he was probably getting set to do cd /data/cross/lart... |
| 07:48:58 | Russ | but then passed out due to lack of caffine |
| 08:04:14 | seletz | oh my |
| 08:04:23 | seletz | sorry, wrong window :} |
| 08:05:04 | seletz | (cd /data/dafit was it, /data if my CF on my dev board. doh.) |
| 08:06:23 | seletz | getting coffee |
| 08:32:14 | Sammy | howdy erikm :) |
| 08:32:30 | erikm | morning, sammy |
| 08:32:41 | Sammy | Russ: init=/bin/sh nothing happen :( |
| 08:34:43 | Russ | erikm: have you read the amd flash doc? |
| 08:35:02 | erikm | Russ: no. I think I have it but I didn't read it |
| 08:35:10 | seletz | moin erik |
| 08:35:13 | Russ | its very different than the intel one |
| 08:35:36 | erikm | Russ: that's what I gathered when I rewrote the flash layer |
| 08:36:32 | Russ | I think I'm going to switch the erase stuff to the toggle bit method |
| 08:36:47 | Russ | while bit 2 is toggling, its erasing |
| 08:37:04 | Russ | if bit 5 gets set to one while its toggling, then there is an error |
| 08:37:33 | Russ | however, if you check again, after bit 5 was set, and its not toggling, it wasn't an error |
| 08:42:31 | Russ | Sammy_mad: if the test program runs, but busybox sh doesn't, then you know where the problem is |
| 08:43:18 | Sammy_mad | Russ: is that linking problem ? or busybox's problem ? |
| 08:43:28 | Sammy_mad | check |
| 08:43:31 | Russ | either |
| 08:44:09 | seletz | Russ: hmm. AMD flashes. Generally, do they work with BLOB ATM? |
| 08:44:30 | seletz | Russ: or isit Dont use them, use INTEL StrataFlashes |
| 08:44:30 | Russ | seletz: there is a problem where if you flash more than one thing, without reseting |
| 08:44:38 | seletz | ugh |
| 08:44:43 | Russ | it gets stuck, and then blob gets overwriten |
| 08:44:46 | seletz | Russ: thats a real issue |
| 08:44:48 | Russ | my code, my problem |
| 08:45:23 | seletz | Russ: is the linux MTD layer capable of handling AMD flashes? |
| 08:45:33 | Russ | ya, it does great |
| 08:45:39 | seletz | phew |
| 08:45:47 | Russ | amd flash is much easier to obtain than intel flash |
| 08:46:02 | seletz | discovered that just this morning :( |
| 08:46:20 | seletz | Russ: they're way cheaper too, as it looks. |
| 08:46:22 | Russ | luckily, its easy to make a footprint that supports both |
| 08:46:48 | Russ | on some of the larger flashes, address lines differ, but for a TSOP48, all you need is three 0 ohm jumpers |
| 08:47:00 | seletz | Russ: ah, cool. |
| 08:47:27 | seletz | Russ: then I'll stick to TSOP48 on my dew design |
| 08:47:40 | seletz | s/dew/new |
| 08:47:47 | Russ | just look at the respective pinouts |
| 08:48:22 | seletz | Russ: do you have some recent price quotes for StrogARMs? |
| 08:48:27 | Russ | nope |
| 08:49:00 | seletz | Russ: hmm. My manufactorer mumbles something in the $38 range. |
| 08:49:16 | seletz | Russ: thats quite expensive IMHO |
| 08:49:34 | Russ | I'd really like to switch to sa1110 |
| 08:49:41 | Russ | as well as bga flash and dram |
| 08:49:43 | seletz | Russ: INTEL germany refuses to quote SA1110 processors. They say "use XScale" |
| 08:49:44 | Russ | er, sdram |
| 08:49:54 | Russ | but it'd be a time consuming redesign |
| 08:50:00 | Russ | seletz: in what quantities |
| 08:50:11 | Russ | I don't trust xscale yet |
| 08:50:29 | seletz | Russ: prototype quantities. And yes, i dont trustxscale too (as of now). |
| 08:50:55 | seletz | Russ: are you going to show up at OLS? |
| 08:51:10 | Russ | I have no way of getting there |
| 08:51:19 | seletz | Russ: pity |
| 08:51:27 | Russ | seletz: I can pass you on to triad, they are getting me sa1100's in quantities of 100 |
| 08:53:49 | seletz | Russ: what's the price for sa1100 in 100pcs lots? |
| 08:53:56 | Russ | don't know |
| 08:54:32 | seletz | Russ: ok, would you please email me the contact infos of triad? or a URL? |
| 09:04:02 | seletz | btw, 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:27 | Russ | maybe you nIOIS16 line is low? |
| 09:07:33 | seletz | nope |
| 09:07:57 | Russ | oh, ok, the inline asm works |
| 09:07:59 | seletz | yes, its lopw |
| 09:08:24 | Russ | what if you use res = *(some (u16 *))? |
| 09:08:30 | seletz | nopw |
| 09:08:35 | seletz | argl |
| 09:08:39 | seletz | no, does not work |
| 09:08:48 | seletz | i casted to unsigned short |
| 09:08:55 | seletz | doesnt work. |
| 09:09:32 | seletz | the only way it really works is when i use ldrh/strh |
| 09:10:06 | Russ | what gcc? |
| 09:10:29 | seletz | eriks toolchain, one moment |
| 09:10:47 | seletz | gcc version 2.95.3 20010315 (release) |
| 09:13:51 | Russ | might ask erikm about that |
| 09:13:57 | Russ | I'm not to wise in that area |
| 09:14:03 | Russ | s/to/too/ |
| 09:14:06 | seletz | i 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:39 | seletz | erikm: are you here? |
| 09:14:41 | seletz | :) |
| 09:16:24 | erikm | yes |
| 09:16:47 | erikm | gcc emits ldrh/strh instructions with -mcpu=strongarm1100 |
| 09:17:04 | seletz | erikm: ugh |
| 09:17:18 | seletz | adjusts CFLAGS |
| 09:17:18 | Russ | erikm: is that enabled in any kernels? |
| 09:17:29 | erikm | Russ: yes |
| 09:17:35 | Russ | which ones? |
| 09:17:37 | seletz | but not in modules i guess |
| 09:17:54 | seletz | modules not in the kernel tree, that is |
| 09:18:05 | erikm | also in modules |
| 09:18:08 | erikm | seletz: ok, then you have to do that yourself |
| 09:18:18 | seletz | thanks |
| 09:18:22 | Russ | erikm: you should add a flash init, to make sure that the flash is in array mode |
| 09:18:29 | Russ | in the case of chain booting |
| 09:18:30 | erikm | Russ: IIRC I submitted a patch for it around 2.3.99-pre8 or so |
| 09:18:34 | erikm | Russ: makes sense |
| 09:19:09 | Russ | anyway, 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:27 | seletz | tests |
| 09:24:40 | Fare | Grrr! |
| 09:24:55 | Fare | Could I go that far without being in SVC mode? |
| 09:25:08 | seletz | erikm: cool, works! even uses an effective adressing mode! Thank you! |
| 09:25:32 | erikm | seletz: *nod*. the blob intel16 flash driver uses the same trick |
| 09:25:35 | Fare | when I load the zImage at 0xc0408000 , blob doesn't die |
| 09:25:47 | Fare | but then the kernel dies when it uncompresses at 0xc0008000 |
| 09:25:57 | Fare | I have the feeling something's rotten. |
| 09:26:44 | erikm | Fare: write out the memory map. look at the size of the zImage. if 0xc0008000 + sizoef(zImage) > 0xc0408000 the kernel will crash |
| 09:27:02 | Fare | no, the sizeof is inferior |
| 09:27:08 | Fare | the kernel is not 4MB long |
| 09:28:06 | Fare | besides, 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:56 | Fare | which 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:32 | erikm | Fare: did you read http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html |
| 09:29:58 | Fare | yup, I did |
| 09:30:11 | Fare | and I got it right. |
| 09:30:30 | erikm | Fare: --> linux-arm-kernel mailing list |
| 09:30:33 | Fare | since the fb is at c0003000, I can *see* the kernel or zImage, when I load it as c0008000 |
| 09:30:51 | Sammy_mad | Ammm...... Russ |
| 09:31:17 | Sammy_mad | Russ: I find out that's busybox's problem ... |
| 09:31:33 | Russ | what was the problem? |
| 09:31:40 | seletz | uclib? |
| 09:32:08 | Sammy_mad | can't run ... |
| 09:32:16 | seletz | hmmm |
| 09:32:19 | Sammy_mad | with uclibc |
| 09:32:56 | seletz | Sammy_mad: have you linked it statically? Or do you provide ulibc in /lib of your root fs? |
| 09:33:48 | Sammy_mad | I linked it dynamic and need uclibc in /lib |
| 09:34:01 | seletz | hmmm |
| 09:34:27 | seletz | I _think_ init must be statically linked, but i'm not sure |
| 09:34:34 | Russ | seletz: nope |
| 09:34:39 | seletz | :) |
| 09:34:40 | seletz | ok |
| 09:34:52 | seletz | Russ: how does it work, then? |
| 09:34:53 | Russ | you just need to check that your binaries are looking for ld*.so in the right place |
| 09:35:02 | seletz | ahh |
| 09:35:11 | seletz | ok, cross-compiler problem |
| 09:35:17 | seletz | yup |
| 09:35:29 | Sammy_mad | how to test busybox for arm ? |
| 09:36:01 | seletz | strings busybox | grep .so ? and look where the path points to? Russ? |
| 09:36:24 | Sammy_mad | I download one with rz into my good tux and run ldd busybox , it's show |
| 09:36:25 | Sammy_mad | # ldd busybox |
| 09:36:26 | Sammy_mad | not a dynamic executable |
| 09:36:56 | seletz | erm. maybe i'd better shut up .... |
| 09:36:56 | seletz | :( |
| 09:36:59 | Russ | you want arm-linux-ldd |
| 09:37:07 | Russ | file will also tell you |
| 09:37:29 | Russ | I think he has busybox linked statically though |
| 09:37:53 | Fare | note 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:08 | Sammy_mad | Russ: so I must use dynamic to run ? |
| 09:38:34 | Fare | (I can *see* those things going on) |
| 09:39:29 | Russ | Sammy_mad: no |
| 09:40:35 | Sammy_mad | uh ? and I don't have arm-linux-ldd to run :( |
| 09:41:00 | Russ | then use file |
| 09:41:02 | Russ | what does file say |
| 09:41:57 | Sammy_mad | Russ: busybox: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, statically linked, stripped |
| 09:42:12 | Russ | that is statically linked |
| 09:42:53 | Sammy_mad | build a dynamic one to test |
| 09:50:08 | Russ | erikm: for the AMD flash to be protected/unprotected, 12V needs to be applied it seems |
| 09:50:25 | seletz | oh no |
| 09:51:06 | erikm | Russ: if you have a controllable switch for that you can put it in the flash driver |
| 09:51:20 | seletz | Russ: that would complicate designs a bit |
| 09:51:29 | Russ | some of the newer chips do it at vcc |
| 09:51:57 | erikm | Russ: or make separate functions enable_protect()/disable_protect(), just like flash_enable_vpp() |
| 09:52:20 | Russ | oi |
| 09:53:13 | Sammy_mad | Russ: why is the file always say static link ? even I do this DOSTATIC = false ? |
| 09:56:52 | Fare | where do I set stack size? |
| 09:57:15 | Russ | Sammy_mad: maybe do a make clean |
| 09:57:16 | Russ | then make |
| 10:00:53 | Sammy_madx2 | Russ: give me a knife |
| 10:01:09 | Fare | what about putting an openbios forth in blob? |
| 10:02:10 | seletz | Fare: yuck |
| 10:02:25 | erikm | Fare: no way |
| 10:02:35 | erikm | Fare: blob embraces the kiss principle |
| 10:04:31 | Russ | Sammy_madx2: its probably not that big of a problem |
| 10:04:45 | Russ | make sure you have the latest version of busybox and uclibc |
| 10:04:58 | Russ | you might try compiling busybox against libc statically |
| 10:05:51 | Sammy_madx2 | ok , downloading the lastest version .. |
| 10:06:28 | Russ | make sure you remove your old uclibc install if you are doing a new one |
| 10:08:25 | Sammy_madx2 | Russ: no , I only change the busybox part |
| 10:09:14 | seletz | SIGLUNCH |
| 10:09:22 | Russ | ok, the new amd flash driver flashed something big |
| 10:09:46 | Fare | call with more than one parameter seems buggy: |
| 10:10:35 | Fare | I called mymemcpy with 3 parameters, and the call was parsed correctly (argv), but passed the 1st paramter thrice to mymemcpy! |
| 10:11:32 | Sammy_ | now go eatting dinner to get more flash air for his head |
| 10:13:09 | Fare | indeed there's argv[2] for all params in call.c ! |
| 10:13:23 | Russ | sammy_ good plan |
| 10:22:43 | Fare | shortly after I write to the zone after the framebuffer, the computer hangs. |
| 10:22:48 | Russ | hmmmm...is this normal? |
| 10:22:55 | Russ | erasing at 0x00100000... scanning down... resume writing at 0x00100000 |
| 10:22:56 | Russ | erasing at 0x00120004... scanning down... resume writing at 0x00100000 |
| 10:22:56 | Russ | erasing at 0x00140004... scanning down... resume writing at 0x00100000 |
| 10:23:05 | Russ | should it always resume at the same sector |
| 10:26:02 | Russ | ah dammit, I killed it |
| 10:44:07 | Fare | now it dies at Uncompressing Linux............... |
| 11:08:56 | Fare | Uncompressing Linux......................... // incomplete literal tree // -- System halted // |
| 11:10:54 | Fare | what does that mean? |
| 11:16:56 | erikm | no idea, never had that. the source usually has comments around an error |
| 11:25:30 | seletz | hi again |
| 11:29:09 | seletz | Fare: ugh. commands/call.c needs a review badly :( |
| 11:30:20 | Fare | seletz: I fixed the bug in my tree |
| 11:30:46 | Fare | (easy enough) |
| 11:31:15 | seletz_ | grrr |
| 11:31:20 | seletz_ | network hiccups |
| 11:31:44 | Fare | bug detected by inflate.c |
| 11:34:55 | Fare | could it be that some DMA device writes stuff somewhere in memory? |
| 12:01:16 | erikm | Fare: only the serial ports can DMA something into memory, the LCD controller only DMAs something out of the memory |
| 12:03:31 | erikm | Russ: it resumes writing at the point where it finds the first non-erased flash location |
| 15:53:31 | prpplague | if you here a loud pop, its just my head exploding from my sinus headache |
| 15:53:45 | prpplague | don't be alarmed |
| 15:56:01 | erikm | loud noises come from outside over here. thunderstorm going on |
| 17:02:14 | sammy_wms | prpplague: come from more beer? |
| 17:04:44 | sammy_wms | btw , if I had headache , sometimes all come from drunk :) |
| 17:05:02 | Sammy_zzz | night all |
| 17:31:18 | Russ | erikm: I wish we would get rain |
| 17:37:00 | erikm | Russ: heh. the sky just becomes clear over here |
| 18:23:19 | prpplague | erikm: nice thunderstorm? love the lighting of a good storm |
| 18:37:27 | Fare | hum |
| 18:37:35 | Fare | does the DMA explanation seem plausible? |
| 18:37:49 | Fare | just what could I be overwriting? |
| 18:40:19 | Fare | what DMA devices exist in a SA1100/SA1101 ? |
| 18:44:16 | erikm | prpplague: this one wasn't as visible as I'd like it to be |
| 18:44:34 | erikm | Fare: only the serial ports can DMA something *into* RAM |
| 18:45:52 | Fare | erikm: hum |
| 18:46:02 | Fare | could that be the case here? |
| 18:46:46 | Fare | what about the pcmcia eth? |
| 18:46:52 | erikm | no dma |
| 18:47:00 | Fare | or the CF memory? |
| 18:47:04 | erikm | no dma |
| 18:47:14 | Fare | grumble. |
| 18:47:20 | erikm | CF memory == very dumb IDE |
| 18:47:30 | Fare | or the USB? |
| 18:47:45 | Fare | tries to imagine what can go wrong |
| 18:48:51 | erikm | USB is a serial port |
| 18:49:04 | erikm | just disable all serial devices |
| 18:49:23 | Fare | how can I do that? |
| 18:49:49 | erikm | see the SA1100 manual |
| 18:49:59 | Fare | is there code in blob for that? |
| 18:50:03 | erikm | no |
| 18:50:19 | Fare | hum. ok. I'll see about it. |
| 18:50:45 | Fare | it seems very plausible to me that WinCE would map its devices in low memory |
| 18:51:09 | Fare | maybe by repeatedly md5'ing the memory, I could detect changes? |
| 18:51:26 | Fare | considers that a good method |
| 18:53:46 | Fare | another tactic would be to leave whole stuff at that place, and have linux use the same statically-allocated buffers. |
| 18:55:11 | Fare | something bugs me, though: |
| 18:55:39 | Fare | why would it kill blob that some dma activity is going on at the place where it puts the kernel? |
| 18:56:06 | Fare | or would the dma device also read something like destination/length from that place? |
| 18:56:52 | Fare | btw, when I blanked the whole zone will 00's or with ea7a710e's it didn't crash |
| 18:57:00 | erikm | Fare: you have to actively tell the DMA engine what to do next |
| 18:57:14 | erikm | Fare: the DMA engines are interrupt driven |
| 18:57:27 | erikm | Fare: and they don't do scatter-gather DMA |
| 18:59:38 | Fare | hum. Then maybe accusing DMA is a wrong track. |
| 19:00:14 | Fare | maybe I'm just dumb and introducing bugs as I fix other ones :( |
| 19:00:46 | Fare | I feel like I should develop a FORTH interpreter first |
| 19:01:13 | Fare | because the compile-download-crash cycle is VERY long |
| 19:01:26 | Fare | whereas with some FORTH, I could debug on the fly |
| 19:02:01 | Fare | (guess why Mitch Bradley crushed single-handedly the swarm of C programmers who desperately tried to implement the Sun boot PROM) |
| 19:09:02 | erikm | Fare: forth for an embedded bootloader is nonsense |
| 19:09:14 | erikm | Fare: right now I can put a bootloader in 30k. try that with forth |
| 19:22:53 | Fare | I can fit forth in 12k |
| 19:23:05 | Fare | did it in the past |
| 19:23:25 | Fare | and that was not a space-efficient forth implementation |
| 19:24:05 | Fare | (the 16-bit PC version was below 8k) |
| 19:25:40 | Fare | including the interactive "compiler". |
| 19:33:02 | Fare | the whole bootloader might end up being small in forth. |
| 19:48:36 | erikm | Fare: a forth interpreter doesn't help you |
| 19:48:57 | erikm | Fare: without a forth interpreter running in SVC mode the system still crashes |
| 19:49:13 | erikm | Fare: besides, a forth interpreter is totally against the KISS principle |
| 19:49:49 | Russ|werk | what would the advantage of forth be, I'm confused |
| 19:50:07 | erikm | Russ|werk: do you know sun openprom? |
| 19:50:52 | Russ|werk | arghh...I think vtun is using something similar to if ((c = fgetc(fp)) != EOF) somewhere where c is a char |
| 19:51:07 | Russ|werk | erikm: ok, so the device have code on them |
| 19:51:15 | erikm | Russ|werk: *nod* |
| 19:51:31 | erikm | Russ|werk: would have made quite a lot of sense for PCI cards, btw |
| 19:51:55 | erikm | Russ|werk: so we wouldn't end up with PC and MAC variants of the same video card, etc. |
| 19:52:46 | erikm | Russ|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:09 | Russ|werk | I would think on a bootloader, you'd want a much simplier bytecode |
| 19:53:29 | Russ|werk | emulate a non-existant minimal micro |
| 19:53:48 | erikm | Russ|werk: forth is quite simple |
| 19:54:16 | erikm | Russ|werk: but I see no point in using it for an embedded device where the number of supported devices is quite limited |
| 19:54:37 | erikm | Russ|werk: and without the bootloader running in SVC mode it doesn't make any sense |
| 19:57:05 | Russ|werk | with byte code, you could do it under 4k |
| 19:57:33 | Russ|werk | and write the original code in c |
| 20:38:10 | Fare | there are C->FORTH compilers |
| 20:38:28 | Fare | there are also bytecode VMs designed to fit on small smartcards |
| 20:38:43 | Fare | (no, not those braindead JVM variants - things like OTA) |
| 20:38:58 | Fare | with compilers from FORTH, C, Ada, etc. |
| 20:40:38 | Russ|werk | ok, it was recording the return status of read with a register int |
| 20:44:32 | Russ|werk | er...hmm |