Subject: Re: Trouble Booting hpcmips Generic NetBSD/Sysinst image (hpcboot.exe
To: Sabahattin Gucukoglu <>
From: Matthew Orgass <>
List: port-hpcmips
Date: 08/08/2004 00:11:34
On 2004-08-07 wrote:
> On 6 Aug 2004 at 23:04, Matthew Orgass <> spoke, thus:
> > On 2004-08-06 wrote:
> >
> > > So, first of all, does or does it (hpcboot.exe - this device runs Windows
> > > CE 2.12) not accept command line parameters?  If it doesn't then, unless
> > > it automatically uses a specific kernel image and boots using a serial
> > > console, or else reads aconfiguration file in a given location (perhaps
> > > the same directory as hpcboot.exe itself), it will not be of any use - do
> > > any of you have suggestions on how to boot this generic gzipped sysinst
> > > kernel image on my device?
> >
> >   I don't know if it has command line options, but it does read and write a
> > configuration file (possibly with a hard coded list of directory names).
> > With the auto boot option it should be possible to configure it to boot
> > without additional user intervention.
> Great!  Have you the spiffy details?  It would be much appreciated!

  Do you mean the file format?  It looks like it is a dump of the
HpcMenuPreferences structure in hpcmenu.h in sys/arch/hpc/stand/hpcboot.
You can access it via cvsweb at:

  You would need to look at the other sources to determine what all the
values mean, though most seem fairly obvious.  Integers should all be
32-bit little endian.  I don't know what a TCHAR is (most likely either
usual char or two byte unicode).  Note that the platid values need to be
from the table in machine_config.cpp (for you, the E100 -- from looking in
pbsdboot the values should be 0x04104300 for cpu (hi) and 0x00c10201 for
machine (lo); these values would need to be converted to little endian),
otherwise the wrong framebuffer values will be used (when viewing it
graphically, some of the machine types displayed do not actually work).
If your hardware does not have a framebuffer chip, you might need to
use serial console to avoid stomping on invalid memory (this might be a
good idea at first anyway).  The id values still need to be set for proper
functioning otherwise.

  The current version of pbsdboot is also available in
sys/arch/hpcmips/stand/pbsdboot and the preference format is in
preferences.c.  This version of pbsdboot can use compressed files.

> >   As I recall, the Casio machines have proprietary PCMCIA controllers; A CF
> > card can be used if configured in CE, however insertion or removal and
> > other cards will not work.  It is possible that Linux users have gotten the
> > documentation or REd enough of the CE driver to be useful, although last
> > time I checked (quite some time ago) Linux had the same limitation.
> I'll start by booting this kernel, and watching the results.  We chose
> NetBSD because it is tracking current software even on this architecture
> and seems to have a real potential.  Our only experience with Linux was
> from's 2.2 build kernel, and that didn't let us do any kind
> of external access, not even to CF - no devices registered, nothing useful
> in /proc. is the place to find about the defunct linux-vr
> project, and they were last seen messing with a 2.3.x series kernel,
> though they seem to have disintegrated since.  I think we'll start with
> the keyboard driver since that is the most important, and we can easily
> mod the source when we find the scancodes.  Exploring the registry reveals
> that the Microsoft keyboard driver is used.  The problem is interesting -
> there are several models of this unit, some accepting braille input and
> some qwerty - two of each, with one in 32-cell braille and the other in
> 18.  If we have anything to contribute, I'm sure we will.

  I ran accross the CyaCE sources not too long ago; I think it was on
sourceforge.  It did look like a minimally modified old version of
pbsdboot, although I have not looked it (or pbsdboot or hpcboot for that
matter) all that closely.  Much of the Linux devlopment was directed at
the lower end machines with minimal XIP ROMs.  One of the main Linux-vr
developers started a company to sell a linux based handheld, but they
didn't stay in business long.  They were working on completely separate
tools to use with XIP.  I don't think there was ever a real distribution
other than that for hpcmips machines.  Those tools are still around
somewhere, and the manufacturer might still be selling the leftover
machines.  They are much more limited than other hpcmips machines
(lacking, if I remember correctly, even one CF slot).

  NetBSD's hpc and hpcmips sources are not great and are almost entirely
undocumented, however they are more complete than what I saw of the linux
sources.  Our portmaster seems to be otherwise occupied at this time, but
it should be possible to find someone to check in whatever you come up
with as long as it follows NetBSD code standards.  I can help you with the
code, but I don't have cvs access.

> One last thing, do you or anyone else here know how to change the memory
> allocation for user and program volatile storage from inside the CE 2.12
> registry, or by modifying a file?  I can't find the values anywhere, but
> we're getting heap overflow with CyaCE, the linux-vr project's bootloader
> based on pbsdboot (now only available for download in modified forms, it
> also having disappeared from the face of the earth).  That program
> requires uncompressed images, which I'd rather wasn't a requirement,
> especially for the sysinst kernel - so using hpcboot would be very
> helpful.  Even so, we would probably still first need to change the
> division of memory for the Sysinst kernel, at least, so it can boot up,
> for a 4m user store and 12m program, as opposed to the default half-and-
> half.  Since we can't do it with CE, it having been locked up more than a
> default installation of OpenBSD, we need to hack it into the device until
> we can boot NetBSD.  Any suggestions?

  I don't see anything either, but I would think it should be there
somewhere.  You might want to look at what the epods hackers did:

  This might help you unlock CE further.  If you have access to a
NetBSD/i386 you can set up the disk from there and cross compile a custom
kernel, which should boot with those settings.  I think you may have
trouble runing sysinst with that little memory.  Those setting might be
sufficent to try loading the sysinst kernel from disk, since I think
"program" memory is used for the loaded image (unless it needs another
copy in memory also).  I don't know if there are Linux tools to write a
NetBSD disklabel or do a ffs newfs (if you are using Linux as a
development platform), however the cross compile should work from there to
test a custom kernel.

Matthew Orgass