[vmlemon]

Not sure if this is best suited to a bug report, or another part of the forum, to be honest.

Over the weekend, I spent some time trying to run an EUserHL-based sample application under QEMU, with limited success, after extracting said sample application and the EUserHL libraries from the package supplied by the Foundation.

A condensed version of the steps that I took (on a preconfigured system, without manually extracting components from .SIS files):

• Download the EUserHL.zip archive from the wiki, and extract it using your favourite ZIP archive management tool
• Run the extracted EUserHL.exe executable to begin the process of copying a number of files to C:\Symbian
• Create a directory structure at C:\svphostfs\sys\bin
• Copy C:\Symbian\epoc32\release\armv5\urel\euserhl_walkthrough.exe and C:\Symbian\epoc32\release\armv5\urel\euserhl.dll to C:\svphostfs\sys\bin
• Run arm-none-symbianelf-qemu-system -M \sf\adaptation\qemu\baseport\syborg\syborg.dtb -kernel \epoc32\rom\syborg.img to start the QEMU-based emulator, assuming that the ROM image and .DTB files are in the specified locations
• Observe that attempting to execute euserhl_walkthrough.exe at EShell fails with a "Not found" error message

I also extracted backup_registration.xml ("file1" according to the .PKG/manifest) from the .SIS file, and copied it to C:\svphostfs\private\10202D56\import\packages\2001B440, although it shouldn't be necessary, given that we don't have the back-up management infrastructure in place, for what it's worth.

I assume that a DLL that euserhl.dll itself depends on is missing, although I couldn't identify any obvious ones from examining the E32Image format binaries. (I suspect that the supplied ELF shared object files might contain a few clues, though).

[cdavies]

elf2e32 tells me it also needs a couple of imports from estor.dll, so you'll need half of syslibs in your ROM too.

I can't remember now, but doesn't the loader also check executable hashes for things on the C drive? It may be the case that either you have to put it in ROM, or write hashes for any executable you want to run. I'm a little fuzzy on that though, I can't remember if all drives marked internal are exempted from checking or just the ROM.

In any case, I'm working on trying to get a minimal textshell ROM built using the old buildrom tools, hopefully I'll have some success shortly and I'll put an OBY file on the wiki. That way, you can simply append the appropriate IBY file and rebuild to get EUserHL in ROM (and any software you want to test, too.)

[vmlemon]

Thanks. If I remember correctly, from what I've been told previously, the S: drive on the guest (which maps to C:\svphostfs\) is managed by the SVPHOSTFSY component, which doesn't perform security/hash checking on executables - so the e32tests example binaries function correctly.

It appears that C:\ on the Symbian Platform guest is immutable, given that it doesn't map to a "physical" drive, and that changes to it don't persist between QEMU sessions.

I was tempted to build a ROM image manually, by adding the DLLs or ELF DSO files to the existing image build files, and hoping for the best, although I'm stuck if that doesn't work out, since I don't have access to the source code for said binary components (they were supplied with SFL'd example source code and headers, but no source code for the actual DLLs/DSOs).

[cdavies]

Yes, this is my problem too. Things panic, and I can't tell why because the only panic reference is the source code. It's a bit of a pain, but I don't really want to wait on other people's schedules for open sourcing things to get started with the things I want to do.

[william_roberts]

Well, you could at least start looking at the source code which *is* available to you. The WSERV 7 panic that you mentioned in a different posting is coming from code in the kernelhwsrv package, and you can search that using OpenGrok.

[william_roberts]

Originally Posted by vmlemon

attempting to execute euserhl_walkthrough.exe at EShell fails with a "Not found" error message

The most likely explanation is a missing DLL, and I think that there is a kerneltrace setting which would help to determine which one. You can set tracing using the eshell "trace" command, but I can't remember which is the best setting to use. I would normally try setting KDLL, which translates to "trace 400", but that only seems to tell me about successes, and doesn't mention the attempts which fail.

Looking at the cross-referencer, it looks as though KFLDR would be a good flag to set, but that's very verbose and I still haven't spotted the right things to look for.

[vmlemon]

Thanks for the help over IM, William. You've been inspirational, as far as figuring out where to start with this mess... (And apologies, if your productivity took a nosedive, today).

I'll have a look to see what else estor.dll imports, and I'll have a play with the EShell trace command, and respective arguments to determine if it's possible to balance verbosity and concise utility, and report back here later with what I come up with.

I can envisage spending more time with ELFtran, in the hope that I can get to the root of this - after all, I'm sure that EUserHL would be a much more useful asset to the community, if it worked under Syborg, too.

[cdavies]

Hah, thanks. Failed to notice that text mode wserv was in the base kernel package. My bad.

Woo, I now have minimal booting textshell rom built with buildrom. I'll play around a little more with adding some components to it, then I'll stick some docs on the wiki. I'll see if I can add all the stuff needed for Euser HL for you, possibly up to and including enough of SWI to use the autoinstalled SIS file.

[vmlemon]

After spending nearly two hours, countless cups of coffee, and much deliberation, I've pretty much found a compromise, and came to the conclusion that EUserHL seemingly doesn't like being executed from QEMU's host-bound file system for a currently unknown reason...

In the meantime, creating a new ROM image based upon the EShell/TextShell demo one, and the extracted components works nicely, albeit at the cost of eating precious ROM space. For those wanting to get started quickly, and avoid running up against the same issues, the new ROM configuration info is included with this post.

• Start by copying C:\sf\os\kernelhwsrv\kernel\eka\rombuild\tshell.oby to C:\sf\os\kernelhwsrv\kernel\eka\rombuild\tshellWithEUserHL.oby
• Add the following two lines to the end of the file, after the "#include <rom\f32\f32.iby>" line:
  

  file=\epoc32\release\armv5\udeb\estor.dll \sys\bin\estor.dll
  file=\Symbian\epoc32\release\armv5\udeb\euserhl.dll \sys\bin\euserhl.dll

• Delete or move the old estor.dll and euserhl.dll files from C:\svphostfs\sys\bin
• Build your new ROM with:
  

  cd \sf\os\kernelhwsrv\kernel\eka\rombuild 
  rom --variant=syborg --inst=armv5 --build=udeb --type=tshellWithEUserHL --name=\epoc32\rom\tshellWithEUserHL.img > \BuildOutputFile.txt

• Run QEMU with:
  

  C:\symbian-qemu-0.9.1\bin\arm-none-symbianelf-qemu-system.exe -M 
  C:\sf\adaptation\qemu\baseport\syborg\syborg.dtb -kernel  C:\epoc32\rom\tshellWithEUserHL.img -serial file:"CustomDUMP.TXT"

• Bask in the glory of your new ROM image, and observe that euserhl_walkthrough works perfectly!

[vmlemon]

Of course, it wouldn't be complete without an obligatory screenshot, although the demo seems to execute a little too quickly for my liking:



Still, it'd be nice if someone (either myself, or someone else) could unravel the mystery of why the DLL seemingly refuses to work from the S drive...

[william_roberts]

The "-serial" is very helpful! It seems that "trace/l 4" is the right command, and the key things to look for are:

Search directory for centralrepository.dll
No suitable image found

The "Search directory for" occurs once per drive, and only if it fails no drive has the relevant binary.
If only the "No suitable image found" message said the filename...

sf/os/kernelhwsrv/userlibandfileserver/fileserver/sfile/sf_lepoc.cpp, near line 3284

		{
		RDebug::Printf("No suitable image found");
+		RDebug::Printf("Failed to find suitable image for %S",&iRootName);
		RDebug::Printf("#NM=%d #UidFail=%d #CapFail=%d #MajVFail=%d #ImpFail=%d", iNameMatches, iUidFail, iCapFail, iMajorVersionFail, iImportFail);
		}

Worth a try...

[vmlemon]

I've discovered some puzzling results, when attempting to use the DLLs with 2 different "vanilla", non-EUserHL-containing ROM images, during testing the "trace /l 4" command, just now.

It seems that if I add the DLLs piecemeal/one-by-one whilst the Platform is running, and an attempt is made to execute euserhl_walkthrough, after each is added, the "Not found" error makes a return - even when both DLLs are present in S:\sys\bin. However, if QEMU is not running when the DLLs are added, it appears that euserhl_walkthrough executes correctly.

Ideally, I ought to revert to using the prebuilt ROM included with the SKK, and a new copy of the EUserHL binaries, to confirm that neither EStor alone, or EUserHL and EStor are resident at runtime as part of the ROM image, or that the binaries on the S: drive have been silently modified in some way.

Attached is a ZIP archive containing 3 logs from these attempts.

[william_roberts]

Originally Posted by vmlemon

It seems that if I add the DLLs piecemeal/one-by-one whilst the Platform is running

That's the problem. Treating the drive as firmware means that the loader will cache the list of executables in sys\bin when it starts up, to avoid having to do filesystem scans later. Once that cache is created, you can put more files into sys\bin, but the loader won't notice.

[william_roberts]

Originally Posted by vmlemon

Thanks for the help over IM, William. You've been inspirational, as far as figuring out where to start with this mess... (And apologies, if your productivity took a nosedive, today).

It was the sort of problem that I'm paid to resolve. You are contributing effort to enable everyone do more with Symbian^3, and I'm glad to be able to help with it. It was also productive for me, because it forced us to dig out the information about tracing and how to find the "Not Found".

Did you make any changes to help track down these problems? If so, please consider contributing them!

[vmlemon]

Sadly, I haven't made any modifications to the Platform source itself, although I'd certainly contribute them back if I did.

Tyson.