Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1 2
RoganDawes wrote:
Bah, I seem to be setting up the memory regions incorrectly. The flash chip is working in legacy mode (CFI mode is not working right now), but I can't actually boot a kernel, since the memory layout is not the same as the vendor u-boot.
Well, after some debugging by one of the U-Boot guys, CFI flash is working with some nasty hacks that need to be cleaned up before being mainlined.
And I can boot the standard vendor kernel, but the ramdisk is not loaded correctly, and so the system does not come up - it panics trying to mount the root fs.
But it is getting really close now!
Soon I'll have to try flash the new image over the existing u-boot.
Offline
RoganDawes wrote:
RoganDawes wrote:
Bah, I seem to be setting up the memory regions incorrectly. The flash chip is working in legacy mode (CFI mode is not working right now), but I can't actually boot a kernel, since the memory layout is not the same as the vendor u-boot.
Well, after some debugging by one of the U-Boot guys, CFI flash is working with some nasty hacks that need to be cleaned up before being mainlined.
And I can boot the standard vendor kernel, but the ramdisk is not loaded correctly, and so the system does not come up - it panics trying to mount the root fs.
But it is getting really close now!
Soon I'll have to try flash the new image over the existing u-boot.
Finally! I have patches for mainline u-boot that provide:
* Flash support - load the kernel and initrd (or JFFS2 fs) from flash
* SATA support - Load the kernel and initrd (if needed) from the SATA disks.
* Network support - Load the kernel and initrd from the network, or run using NFS mount.
on DNS323 B1 hardware.
The only thing not tested yet is booting from poweroff. Up until now, I have been chainloading my u-boot from the existing vendor u-boot.
If anyone has a working JTAG setup, and would like to try this, please let me know. My JTAG setup has not yet arrived.
Offline
Does it support loading from usb? I'd be very interested in that (as well as a 128 MB capable build). I unfortunately don't have JTAG working to help with initial testing.
Offline
jdoering wrote:
Does it support loading from usb? I'd be very interested in that (as well as a 128 MB capable build). I unfortunately don't have JTAG working to help with initial testing.
It doesn't support USB yet, but it may come soon.
There is no reason it should not support 128MB, though. Just a question of programming :-)
Just to make sure I understand, though. You've upgraded your RAM, but haven't added JTAG yet? Brave! :-)
Which hardware version do you have, by the way? I've been doing all my testing on a B1.
Rogan
Offline
RoganDawes wrote:
jdoering wrote:
Does it support loading from usb? I'd be very interested in that (as well as a 128 MB capable build). I unfortunately don't have JTAG working to help with initial testing.
It doesn't support USB yet, but it may come soon.
There is no reason it should not support 128MB, though. Just a question of programming :-)
Just to make sure I understand, though. You've upgraded your RAM, but haven't added JTAG yet? Brave! :-)
Which hardware version do you have, by the way? I've been doing all my testing on a B1.
Rogan
Just another thought: If you are wanting to run your OS from the USB stick, you can do that as is, with the current loader. E.g. Debian can be installed to a USB stick, and it works fine.
Offline
Yeah, took the risk a while back: http://dns323.kood.org/forum/viewtopic.php?id=2388. I had hardware for JTAG but never bothered getting it working since things went okay and the JTAG info was somewhat spotty then.
B1 hardware. I've been considering using the current Debian loader option. I thought it would be nice to skip the firmware part if you come up with a solution that can go straight from bootloader to disk. Probably doesn't make much difference though.
What's the primary use-case you're interested in compared to the currently supported options?
-Jeff
Offline
jdoering wrote:
Yeah, took the risk a while back: http://dns323.kood.org/forum/viewtopic.php?id=2388. I had hardware for JTAG but never bothered getting it working since things went okay and the JTAG info was somewhat spotty then.
B1 hardware. I've been considering using the current Debian loader option. I thought it would be nice to skip the firmware part if you come up with a solution that can go straight from bootloader to disk. Probably doesn't make much difference though.
What's the primary use-case you're interested in compared to the currently supported options?
-Jeff
Hi Jeff,
Well, part of the motivation was to have some kind of fall back position in case the debian installation on the NAS becomes unusable for some reason. Currently it requires obtaining a serial cable, flashing an old vendor kernel and ramdisk, and redoing the installation (or else removing the disk, and repairing it using a second Linux installation with a spare SATA connection).
I thought it would be handy to have the boot loader attempt to boot from the disk directly (ext2fs), and then fall back to booting from the flash. Or else, allow remote flashing of a new firmware over the network, for example.
Of course, the truly obvious solution (to have an emergency shell available in the Debian ramdisk, in case the proper init sequence could not be completed) has not been properly explored.
I imagine that a copy of the passwd/shadow files could be included in the ramdisk, an emergency telnet daemon could be started on a non-standard port, and the telnet daemon could be killed if e.g. openssh was successfully started. And this would be more generally useful, too!
Ah, well, it's been fun exploring the lower levels of the stack :-)
Offline
Pages: 1 2