Hi! I'm trying to get Kamikaze brcm47xx run on a WAP54g v2. It has only 2 MB flash, so the process involves a lot of trial and error. So for basic testing I decided to go with an NFS root setup to avoid the need to reflash after each filesystem change. This works OK after disabling
ifconfig $ifname 0.0.0.0 down at the end of target/linux/brcm-2.4/base-files/etc/preinit.arch. (It took some time to realize it's hard linked to brcm47xx. Nasty...) Why is that ifconfig there at all? (A side note: from time to time I'm swamped with 0 length 000 mode files in build_dir. That means a flood of errors from find etc. Anybody knows why they are created?) Now to my main points: 1. I can also boot new kernels without flashing from CFE (v1.0.37) by boot -elf 1.2.3.4:vmlinux.elf Dandy. But setenv -p STARTUP "boot -elf 1.2.3.4:vmlinux.elf;" doesn't make this automatic on next reboot, contrary to documentation: STARTUP has the value "go;" again. What do I miss here? 2. This method is limited to kernels smaller that 3 MB uncompressed, as trying to load larger ones overwrites CFE itself which has: Text (code) segment: 0x80300000 - 0x80309420 (37920) This is documented in OpenWrtDocs/KamikazeHowto as "CFE/PMON TFTP maximum image size limitation", with a note that it could be worked around in principle. But is there a working solution available? (Even lzma-loader could do the job if it read the compressed image by TFTP instead of from a flash partition or did some other clever trick...) 3. Using Ctrl-C on the console to enter failsafe mode does not work: some ^C-s appear on the screen, that's all. Is it a bad terminal setting, or what? 4. Why isn't /dev/console opened as stdin/stdout/stderr at the beginning of /etc/preinit? How is it possible to have no console at all? Why is /dev/pty/ptmx trickery needed? 5. http://xinu.mscs.mu.edu/Flash_driver says that different erase block layouts are possible across a single flash chip (at least that's what I understand from it). For my purposes using a region with smaller blocks for jffs2 would be a big gain, as currently I've got a single 64 KB erase block for it, which obviously does not fly. Is it really possible? 6. Otherwise I'd have to go back to using nvram for configuration, as wasting another 64 KB flash for that isn't really an option on this device. Or perhaps using cache/erase/write on a single block through FTL and another filesystem... I'd be grateful for any insight on this. 7. On the other hand, probably quite some space could be gained by disabling CONFIG_BLOCK, if squashfs didn't depend on it. What do you think, is this dependency hard, or could be reasonably get rid of? (By the squashfs developers, of course.) 8. Why is noinitrd on the command line? 9. I compiled FILE_LOCKING out of my kernel, and it broke busybox lock at least, giving funny effects in failsafe mode. Should I expect futher serious breakage? 10. That's all for now, thanks for reading this far. 11. Thanks as well for incorporating my broadcom-diag patch so quickly. :) 12. This hardware (WAP54g v2) is marked "work in progess" on the Wiki. Who is working on this? We should make contact. -- Regards, Feri. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
