Re: how does "hpcboot.exe" work?
Warner Losh <[email protected]> Fri, 23 May 2025 08:05:12 -0600
| Newsgroups | gmane.os.netbsd.ports.mips.devel |
|---|---|
| Message-ID | <CANCZdfo+TKnsS_HsURmozP_6mBFKZkRcZ3YxrHafsL9BFZ_tXA@mail.gmail.com> |
On Fri, May 23, 2025 at 6:52 AM DiTBho Down in The Bunny hole <[email protected]> wrote: > > Thanks, I expected it to be a separate project, that is, outside the > official sources. > However there is no documentation, or rather the "sources" are the > documentation. > > The README only explains how to use it, I'm trying to understand how > it works internally. > > I am a bit shocked that "Windows-CE-v1" has no memory protection. > It seems a bit like the same trick that was used with "bootX" on > old-world PowerMacs (like e.g. wallstreet laptops), to load and start > the linux kernel through macOS-v9. I think the key to understanding it is looking at the MemoryManager_LockPages code. This code is used by the different loaders to lock pages into memory. It's a bit twisty, but the lock_pages function appears to come from WinCE itself. If you thread it out, we have lookup LockPages and UnlockPages in the coredll.dll library: void * Architecture::_load_func(const TCHAR * name) { if (_dll == NULL) _dll = LoadLibrary(TEXT("coredll.dll")); if (_dll == NULL) { HWND owner = HpcMenuInterface::Instance()._root->_window; MessageBox(owner, TEXT("Can't load coredll.dll."), TEXT("WARNING"), MB_ICONWARNING | MB_OK); UpdateWindow(owner); return NULL; } return reinterpret_cast <void *>(GetProcAddress(_dll, name)); } and then we use this function pointer in the MemoryManager_LockPages class. I've not puzzled out the next steps after "so you have it locked into memory" but that would be the next step. There may be a talk that was recorded at AsiaBSDCon in the early 2000s when all this hacking was going on about it. Otherwise you'll have to puzzle through the code. The code itself is fairly well written, but working backwards from MemoryManager_LockPages to find it was a little tedious. However, it's also instructive. if you're not otherwise comfortable with C++, I'd suggest you start there. This is a very C++ program with pretty good object abstractions that you need to understand to puzzle things out completely. But taking a moment to puzzle will be rewarded. ${arch}/${arch}_boot.cpp is where to start. It also does a lot of different guessing about different aspects of WinCE that you'll likely need to know as well. You can tell that lots of people did lots of tinkering to discover how to use the WinCE interfaces to puzzle out a lot of critical information about the machine at runtime, but this was also augmented by some use of tables to know things like frame buffer addresses and geometry (apparently). Also, to get it to boot directly to Linux or NetBSD, you're going to have to replace the boot rom cards. They live at the reset vector address for MIPS and without changing those out, you'll not be able to really boot directly (though it all depends on how direct you need to be). I looked into it briefly since the MoblePro and z50 both had replaceable cards for this. But the cards were populated by actual mask-programmed ROMs, not flash of any type, at least according to the chip codes I looked up... The ROM chips are well documented (or were ages ago when I was looking), just not their contents. I was looking for good suspend / resume support and wound up down that rabbit hole to these parts. Good luck! Warner P.S. It also looks like hpcmips used sys/arch/hpcmips/stand/pbsdboot which may be simpler and easier to understand. I noticed this after I puzzled through hpcboot. > On Fri, May 23, 2025 at 2:39 PM Martin Husemann <[email protected]> wrote: > > > > On Fri, May 23, 2025 at 02:00:05PM +0200, DiTBho Down in The Bunny hole wrote: > > > I can't find the source code and documentation for "hpcboot.exe". > > > > The source is in src/sys/arch/hpc/stand/hpcboot, there are some notes > > about it in src/sys/arch/hpc/stand/README. > > > > Martin