Bricked my kurobox

[blu at vl.com (Tom Metro)]

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.