00:20:00 | BZFlag | Russ: where's that reflash app you wrote? |
00:20:45 | Russ|werk | which one? |
00:21:29 | BZFlag | any. all. ;-) |
00:21:43 | BZFlag | the one that runs from user space and forces a reboot afterwards. |
00:22:58 | BZFlag | watches lotr while hacking. ;-) |
00:24:27 | BZFlag | don't you hate it when you get stabbed by a mordor blade? |
00:39:43 | BZFlag | Russ|werk: you around? you remember the app I speak of? you had one that bb init runs? |
00:39:58 | Russ|werk | BZFlag: thats jflash |
00:40:04 | Russ|werk | oh, that |
00:40:04 | Russ|werk | right |
00:40:21 | Russ|werk | which part? the /linuxex script? |
00:40:45 | Russ|werk | I was thinking jtag, I have an app that flashes from kernel space over jtag... (mtd map) |
00:41:31 | BZFlag | ah. yeah I meant the bb init one. might be /linuxex |
00:41:50 | BZFlag | does it just copy bb + libc etc to a ramfs first? |
00:42:19 | BZFlag | I just want to dd a new rootfs and then reboot. just looking for an easy way to reboot after the dd. |
00:42:23 | Russ|werk | it copies a very simple staticly linked flash program |
00:42:41 | BZFlag | that sounds great. ;-) |
00:42:47 | Russ|werk | the flash program opens /out (copied from /dev/mtd4) |
00:43:23 | Russ|werk | then opens mmaps /image.bin (image file) |
00:43:34 | Russ|werk | uses ioctl's to erase the flash |
00:43:52 | Russ|werk | then starts doing write()'s to flash |
00:44:07 | BZFlag | then how do you reboot? |
00:44:18 | Russ|werk | closes everything, sync(), sleep(3), reboot(LINUX_REBOOT_CMD_RESTART); |
00:45:15 | BZFlag | is there a reason for the sleep(3)? or just to be safe? |
00:46:43 | Russ|werk | just to be safe |
00:46:57 | Russ|werk | it doesn't hurt anything |
00:46:58 | BZFlag | source? (if you don't mind) |
00:47:11 | Russ|werk | sure |
00:48:10 | Russ|werk | to get any debug output, you'll have to redirect stdout/err to ttySA0 |
00:48:18 | BZFlag | gack. fw inhibited. |
00:48:38 | BZFlag | email? Tim@Rikers.org |
00:48:48 | Russ|werk | http://68.2.221.180:8000/flash.c |
00:50:18 | Russ|werk | compiled statically, its 18k |
00:51:22 | BZFlag | uclibc? |
00:51:49 | Russ|werk | ya |
00:51:59 | BZFlag | sweetness. thanx! |
00:51:59 | Russ|werk | arm-uclibc-gcc -Os -Wall -static flash.c -o flash |
00:52:10 | Russ|werk | and then strip it |
00:52:15 | BZFlag | yep |
00:52:46 | Russ|werk | er, I'm actually forgetting to strip it |
00:52:47 | BZFlag | so it chroots and then calls itself? |
00:53:15 | BZFlag | if (!strcmp(basename(argv[0]), "chroot")) chroot_main(argc, argv); |
00:53:15 | BZFlag | else flash(); |
00:53:22 | Russ|werk | nm, I am |
00:53:32 | Russ|werk | no, you can ln -s flash chroot |
00:53:46 | Russ|werk | pivot_root . old |
00:53:46 | Russ|werk | exec ./chroot . ./flash |
00:54:10 | Russ|werk | so that way you don't have to worry about getting bb chroot to find bb and uclibc |
00:55:02 | Russ|werk | (LD_LIBRARY_PATH=./old/lib exec ./old/bin/busybox chroot . ./flash) or something |
00:55:05 | BZFlag | hmm.. if you do a pivot_root, why do you need to do a chroot? |
00:55:25 | Russ|werk | so then you can umount /old |
00:55:41 | BZFlag | just an exec would get you that, no? |
00:55:52 | Russ|werk | nope |
00:55:59 | BZFlag | why not? |
00:56:25 | Russ|werk | because lib is now in /old/lib |
00:56:30 | BZFlag | I do that on the tux /linuxrc. exec /linuxrc, which then execs sbin/init. I can unmount after the second exec. |
00:56:38 | Russ|werk | so bb won't know where /lib is unless you ln -s stuff |
00:57:11 | Russ|werk | really, for me, since I'm on a cramfs, its not critical that I umount it |
00:57:16 | BZFlag | but if you exec /foo (linked to flash) which just execs /flash then you would be ok. |
00:57:35 | BZFlag | no libs would be open. |
00:57:57 | Russ|werk | there isn't only one way to do it |
00:58:14 | Russ|werk | chroot is really simple anyway |
00:58:21 | BZFlag | ok, just asking. ;-) |
00:58:31 | Russ|werk | chroot(argv[1]), chdir("/"), execvp(argv[2], argv + 2); |
00:59:48 | BZFlag | I'm just thinking that an execvp would be enough. |
01:00:29 | Russ|werk | probably, I think I read it in the kernel piviot_root doc |
01:01:00 | BZFlag | I think the bb pivot_root does the equiv of a chroot. |
01:01:35 | Russ|werk | ya, I got that from Documentation/initrd.txt |
01:02:12 | Russ|werk | "- chroot to the new root afterwards" |
01:06:24 | BZFlag | hmm. perhaps I'm doing it wrong. /me goes off to experiment. |
01:07:01 | Russ|werk | don't forget, after /linuxex start running, you need to > /dev/ttySA0 (or maybe /dev/console) to see anything |
01:13:19 | BZFlag | right. thanx. |
01:13:50 | BZFlag | might just work on vercel, as there is a console/kybd |
02:06:57 | Sammy | uh , lot of typhoon .... |
02:07:37 | Russ|werk | pretty wet, eh? |
02:08:10 | Sammy | I hate that ... |
02:08:46 | Sammy | Russ|werk: do you check mtdblock.c again ? |
02:09:53 | Russ|werk | what do you mean? |
02:10:13 | Sammy | about the mount -a hang problem ... |
02:10:43 | Russ|werk | still getting it? |
02:11:24 | Sammy | I put it on my puppy board , yes , but tux I change to 2.4.18 No |
02:11:45 | Sammy | how can I fix that prob ? |
02:12:10 | Russ|werk | does grep invalidate_device drivers/mtd/mtdblock.c return anything? |
02:12:42 | Russ|werk | this is probably the problem: |
02:12:43 | Russ|werk | http://lists.infradead.org/pipermail/linux-mtd-cvs/2002-May/002271.html |
02:13:03 | Russ|werk | http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2002-March/007940.html |
02:13:47 | Sammy | drivers/mtd/mtdblock.c |
02:14:00 | Sammy | invalidate_device(inode->i_rdev, 1); |
02:14:31 | Sammy | check... |
02:18:30 | Russ|werk | just take that line out |
03:07:05 | Sammy | ok , fix it ...thanx Russ |
07:50:24 | mmatten | hi |
08:28:44 | Sammy | is comming ... |
08:30:22 | Sammy | typhoon |
08:30:56 | Sammy | double blob site |
08:31:16 | Sammy | any different ? |
08:31:50 | erikm | yes, we moved to oftc because all other relevant channels moved |
08:32:30 | Sammy | erikm: and bot ? |
08:32:54 | erikm | lxrbot will move when I have time to visit the uni |
08:34:28 | Sammy | will here be shotdown after finish move ? |
08:35:36 | Sammy | er shutdown |
08:35:55 | Sammy | erikm: you must be more busy this day ... |
08:40:25 | erikm | I think I'll remove the channel |
11:02:46 | harsha | hello everyone |
11:03:19 | harsha | does the blob-2.-.5 support the Sleep Wakeup completly |
11:03:49 | harsha | or is still a lot of tweaking needed to get it up |
11:04:06 | erikm | harsha: should work |
11:04:27 | harsha | no because I have been trying it and no progress |
11:04:47 | erikm | try the latest CVS version |
11:05:10 | harsha | the other thing is DRAM and Peripheral HOLD as given in the datasheets of SA1110 says something diferrent about them |
11:05:17 | harsha | let me try the CVS |
12:52:46 | harsha | erik, how is the assbet supposed to wake, if the serial port hasnt been configured |
12:53:20 | harsha | if the blob branches to PSPR without initializing the serial ports |
12:57:54 | erikm | ... which is exactly how it should be done |
12:58:28 | harsha | but how will the kernel come up then, if the serial ports are not initialized |
12:58:37 | harsha | I am a little confused, so please dont mind |
12:58:48 | erikm | the kernel will reinitialise all hardware |
12:59:29 | erikm | the idea was to make the bootloader part as simple as possible and let the kernel do the dirty work, simply because the kernel already knows in what state the hardware should be |
12:59:41 | erikm | s/idea/design objective/ |
13:01:04 | harsha | ok |
13:01:20 | harsha | thank you |
14:01:34 | Speedy2 | Blob |
14:10:47 | prpplague | morning all |
14:10:54 | prpplague | seems we have some new faces |
14:13:59 | Speedy2 | Heh |
14:15:15 | erikm | prpplague: note that seletz, mmatten and me moved to oftc.net |
14:15:31 | Speedy2 | Hey Erik |
14:15:42 | erikm | waves |
14:16:57 | Speedy2 | Is LART going to move to the SA-1110? |
14:17:03 | Speedy2 | Can you guys even get SA-1100s? |
14:21:34 | prpplague | erikm: you got a #blob on oftc? |
14:34:43 | erikm | Speedy2: lart is not moving to sa1110. there are already enough sa1110 designs out there |
15:47:44 | Fare | Gakuk! |
15:48:04 | Fare | can anyone here help with my linux porting problem? |
15:49:18 | erikm | food |
15:49:59 | Fare | indeed, food will help me |
15:50:12 | Fare | I mean, without food, I'll have much more troubles trying to port linux |