Bricked my kurobox
Tom Metro
blu at vl.com
Mon Apr 30 21:26:02 EDT 2007
John Abreau wrote:
> It's a headless box. You power it on, wait for it to query the
> DHCP server, then telnet to it. The flash ROM boots a 2.4 Linux kernel
> in a tiny ramdisk with busybox, accessible via telnet and ftp.
...
> ...the flash ROM, which the wiki refers to as the Emergency
> Maintenance boot ROM.
OK. And I gather from your earlier "bricking" comment that when you ran
into problems with the hard drive that you were no longer able to access
it via telnet?
> The same conditions apply when booting from a hard drive; you wait
> for the system to boot, then access it via telnet, ssh, or whatever.
...
> The entire OS is written to disk; the flash ROM is apparently used
> only to install the OS to the hard drive, then it runs from the
> hard drive exclusively.
It would be helpful to understand how it is actually booting. In one
scenario, it simply installs a bootable OS on the hard drive, and checks
there first for bootable media. In that case, the "Emergency Maintenance
boot ROM" only gets booted if the hard drive fails to boot in a manner
that the BIOS can detect (as opposed to a boot attempt that hangs).
In the other scenario, it might always boot the "Emergency Maintenance
boot ROM," but then hand off control to a kernel on the hard drive, if
found. This would imply that the hard drive would need to be configured
in a specific way to work with this setup. But I'd say this second
scenario is less likely.
Given that, I'd expect it to boot the "Emergency Maintenance boot ROM"
just fine if the hard drive was removed.
This may also imply that having a JTAG cable won't help you resolving a
hanging hard drive boot, as without the boot ROM running, there won't be
anything responding over the serial interface. Although it might provide
a prompt early in the boot process where you might be able to halt the
boot or specify a different kernel to try.
There may even be some mechanism force the Emergency Maintenance boot
ROM to boot without removing the hard drive. Conceivably, it may use a
process where you remove the hard drive, boot the boot ROM, alter a
setting stored in flash that controls the boot sequence, and then
reattach the hard drive and reboot.
> I suppose another alternative would be to put the gentoo tarball
> back onto the drive while it's in the usb enclosure, then
> stick it back in the kurobox. I'm not sure if that would be enough,
> though, and any further configuration of gentoo on the drive would
> probably fail since the kurobox is a ppc and my other systems are
> all x86.
I assume the Gentoo distribution you tried installing was one
specifically tailored for this box.
It's typical to have bootable drive images made available for embedded
devices like this. If the Gentoo supporters of the the kurobox don't
provide this, you may want to see what other distributions are available.
While if everything goes well, FTPing files to the kurobox and doing an
in-place install is probably the easiest approach if you already have
the drive installed, if you're willing to remove the drive, installing
an image onto the drive from another computer is likely a more reliable
approach.
>> If the box can accept multiple IDE drives, you might want to consider
>> using a CF adapter as described above, providing you can hack it to
>> bypass booting from the internal flash.
>
> The box is tiny, and there's not enough room to swap the IDE cable
> for one with an additional connector on it.
Make a custom cable?
Any USB ports? Though even if there were, chances aren't great that its
BIOS would know how to boot from a USB device, or if it did, that you
could set that to have a higher boot priority than the hard drive.
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the Discuss
mailing list