OSDev.org

Hi.

I have recently managed to build (makefile.prm in PDPCLIB) 32-bit ARM PE executables using UEFI and running under qemu-system-arm on my x64 laptop. One of the outstanding points of confusion is why edk2 under qemu requires the machine to be 1c2 and doesn't accept 1c0. Before reporting a bug (I've read the code - only 1c2 is coded) to edk2/tianocore, I'd like to find out what real machines do.

Apparently I'm late to the party:

https://windowsreport.com/windows-10-arm-devices/

"So, when will Windows 10 for Qualcomm be available? Microsoft representatives only mention ‘next year’, but some speculation is pointing towards the fall of 2017."


But maybe I'm later than that. ARM v8 64-bit came out in 2011. I'm after 32-bit.

The ARM Microsoft Surface Pro 2 had 32-bit UEFI as far as I know. That's around 2014.

I don't care if the processor *also* supports 64-bit, I'm mainly interested in the UEFI API. With PDOS/386 I use legacy boot, but I don't have that situation with ARM and can go straight to UEFI.

I have no experience of Windows on ARM. I would like to create ARM PE executables too at some point, to run under Windows for ARM. That requires more work as I need to investigate whether there is an msvcrt.dll the same as 32-bit x86. And I will want to build my own kernel32.lib too, assuming that is a thing on ARM.

I have bought several Windows 10 licenses, and I believe that allows me to download an ARM version of Windows which I could then run under qemu-system-arm too. So that's probably something to do too.

But the most important thing is to boot directly on a 32-bit ARM UEFI machine instead of qemu. So I would like to buy a (presumably old) machine.

I read that decades ago there were very cheap netbooks that ran Windows. It's unclear to me what the difference between Windows CE and RT is. I will be doing everything from the command line, and I will be building all of my own software (on PDOS/386, cross-compiling by running gccprm etc). So I don't need fancy features. I just need a test environment to use occasionally. Although if the option exists, I would potentially program directly on a Windows ARM machine.

So - what should I buy? I'm ideally after a laptop. The Surface is actually a tablet with a kickstand. I can use that if required, but I much prefer a proper laptop with a proper hinge - easy to physically handle. I need a full sized keyboard so that I can touch-type.

I could use some other machine like a Raspberry Pi, but it doesn't have UEFI in the firmware. I believe there are add-ons I can get, but I don't want add-ons. If I do that I may as well just use the "add-on" software called qemu-system-arm. And I can potentially run qemu-system-aarch64 with kvm on a Pinebook Pro too. But that's a separate exercise.

Any advice?

Thanks. Paul.

The UEFI specification says EFI binaries for 32-bit ARM must have the machine type set to 0x1C2.


Windows CE was customized for each device it ran on. Windows RT was just Windows 8 (with extra limitations).

Thanks for clearing that up! I have now released new executables to build ARM PE executables.

Not only that, but I have a Pinebook Pro, and I have been able to enable kvm using the instructions that I documented in efistart.c. Although I haven't yet run anything CPU-intensive that would provide positive "proof" that it is working. But all indications are that I have (basically) got myself a new 32-bit ARM PC that is independent of Linux.

However, floating point still doesn't work. I get a crash with unknown opcode when I do ldfd (which is generated by gcc 3.2.3). I believe the problem may be that floating point isn't enabled (64-bit is enabled by default I believe). I have attempted to translate this:

https://developer.arm.com/documentation ... ng-the-fpu

into gas syntax:

.globl ___trythis
___trythis:

#CPACR EQU 0xE000ED88
.set CPACR, 0xE000ED88

# gets here
LDR R0, =CPACR
# gets here
LDR r1, [R0]
zloop: b zloop
# doesn't get here
ORR R1, R1, #(0xF << 20)
STR R1, [R0]
#DSB
.long 0xf57ff04f
#ISB
.long 0xf57ff06f
# doesn't get here
mov pc,lr


But as per comments, it is failing to read that high memory address (data abort exception).

Note that I am back to using my x64 computer, so I am running qemu-system-arm instead as kvm is not available either way, ie:

qemu-system-arm -cpu cortex-a15 -M virt -pflash edk2-arm-code.fd -drive file=fat:rw:armtest -device ramfb -device qemu-xhci -device usb-tablet -device usb-kbd

Am I doing something wrong with either the way I run qemu or the assembler translation to gas syntax?

Thanks. Paul.

I only have a choice of cortex-a7 and a15 for qemu-system-arm machine virt (not sure if I should change to a different machine).

Regardless, I tried a7 instead of a15 and got some code from the a7 documentation:

https://developer.arm.com/documentation ... ch02s01s02

I tried this:

.globl ___trythis
___trythis:

#CPACR EQU 0xE000ED88
.set CPACR, 0xE000ED88

MRC p15, 0, r0, c1, c1, 2
zloop: b zloop
# bits 11:10 to be set
#ORR r0, r0, #2_11<<10
ORR r0, r0, #0xC00
MCR p15, 0, r0, c1, c1, 2

And it fails on the MRC with unknown opcode.

Not sure if it is related to my use of binutils 2.14a.

But the assembler listing shows:

510F11EE MRC p15, 0, r0, c1, c1, 2

and this:

http://disasm.pro/

shows the hex seems to be correct.

BFN. Paul.

It occurred to me - even if I can get this to work, it looks to me like it requires privilege.

On real hardware (a 32-bit ARM processor in a Netbook), I also can't use floating point (at least "ldfd") when using PdAndro.

And in that unprivileged environment I won't be in a position to enable floating point if it isn't already enabled.

Therefore it makes more sense to compile with -msoft-float and have a supporting library.

I need these stubs to be made real:

.globl ___addsf3
.globl ____addsf33
___addsf3:
____addsf3:

.globl ___adddf3
.globl ____adddf33
___adddf3:
____adddf3:

.globl ___subsf3
.globl ____subsf33
___subsf3:
____subsf3:

.globl ___subdf3
.globl ____subdf33
___subdf3:
____subdf3:


I am happy to have the assembler routines call C code - or indeed - have C code directly executed - to make the code more portable in case I need it again. I don't care about the speed of floating point. But it would be good if it worked.

I need something that is explicitly public domain. I'm currently searching. If anyone knows of something, please let me know. Thanks.

Those are provided by libgcc.


No you don't. If you can use GCC even though it's not public domain, you can use libgcc.

Yes, I know.


That doesn't satisfy my needs. I don't want copyright material linked into my executables. Currently I am trying to write those stubs in C, to at least work for whole numbers in floating point - by converting them to integers. Better than nothing, and better than compromising my executables.

And before you say "LGPL allows ..." - wrong way around. Ask the LGPL people why they didn't make their code public domain - and refuse to do so - and you will have your explanation as to why I am after public domain replacements.

Then you can't use GCC at all. GCC always includes copyrighted material in the executables it generates, whether you link with libgcc or not.


It's not LGPL, it's GPL with the GCC runtime library exception. If the runtime library exception is good enough for you to use GCC, you can use libgcc too. If the runtime library exception is not good enough for you to use libgcc, you can't use GCC either.

No it doesn't - not for my use anyway. It isn't aware of any of the source code it is given. It is entirely public domain.

And the output that I use is assembler. They don't own assembler mnemonics either.

And even those disappear before they get into the executable - and I'm using a public domain linker to do that even. And a public domain assembler for that matter.


Actually it's neither (at least the version that came with gcc 3.2.3). Still copyrighted though. And still has a condition. Of course most will say that that condition isn't onerous. But try asking him to drop that restriction, drop the copyright statement, and add a public domain statement instead, and it turns out that that's a big deal after all.

D:\devel\gcc\gcc>e floatlib.c

/*
** libgcc support for software floating point.
** Copyright (C) 1991 by Pipeline Associates, Inc. All rights reserved.
** Permission is granted to do *anything* you want with this file,
** commercial or otherwise, provided this message remains intact. So there!
** I would appreciate receiving any updates/patches/changes that anyone
** makes, and am willing to be the repository for said changes (am I
** making a big mistake?).

Warning! Only single-precision is actually implemented. This file
won't really be much use until double-precision is supported.

However, once that is done, this file might make possible
cross-compilation for an IEEE target machine from a non-IEEE
host such as a VAX.

If you'd like to work on completing this, please talk to [email protected].

--> Double precision floating support added by James Carlson on 20 April 1998.

**
** Pat Wood
** Pipeline Associates, Inc.
** [email protected] or
** sun!pipeline!phw or
** uunet!motown!pipeline!phw
**
** 05/01/91 -- V1.0 -- first release to gcc mailing lists
** 05/04/91 -- V1.1 -- added float and double prototypes and return values
** -- fixed problems with adding and subtracting zero
** -- fixed rounding in truncdfsf2
** -- fixed SWAP define and tested on 386
*/

/*
** The following are routines that replace the libgcc soft floating point
** routines that are called automatically when -msoft-float is selected.
** The support single and double precision IEEE format, with provisions
** for byte-swapped machines (tested on 386). Some of the double-precision
** routines work at full precision, but most of the hard ones simply punt
** and call the single precision routines, producing a loss of accuracy.
** long long support is not assumed or included.





As far as I know, for my use, that is not true. I'm happy to be corrected if you can point to anything at all that goes into my executables that you believe belongs to the FSF.

And as to my original question, I now have something that will hopefully do the trick with a bit of work, from a public domain CPU (Plasma - almost the same as MIPS):

https://github.com/public-domain/plasma ... nel/math.c

BFN. Paul.

Correction - the assembler for ARM is from binutils. It is the 80386 target that uses pdas, which is public domain. But that doesn't alter the main argument.

Also - those routines that I linked to are only single precision, so I altered gccarm etc to only use single precision and now it works.

Except that some of the source code comes from GCC itself, under GCC's license.


Capitalism discourages releasing works to public domain by threat of starvation. I'm glad you're in a position where you don't have to worry about that, but not everyone is so lucky.


I'm only familiar with the freestanding headers and libgcc, I wouldn't be able to tell you what other pieces are there. But also, it doesn't matter because those pieces are all under a license that allows you to do whatever you want with the compiled code as long as you used GPL code to compile it.

I have no idea what you are talking about. As I said - I only give it my own source code.


That person has copyrighted freeware. He's not being paid either way. But despite that, he won't drop the copyright notice. I fully expect people to copyright commercial software that they are relying on to prevent starvation.


I don't use any of that. I use my own public domain PDPCLIB.


"whatever you want" is incompatible with "as long as you".

It is only public domain where you can do whatever you want.

Anything else, the undisputed copyright holder can take you to court for perceived violation of their understanding of their restrictions. And they copyrighted it for a reason - to impose some sort of restriction. And I don't want to face a judge that points that out - "look - they went to the effort to copyright it - they clearly had a desire to hold something back - and that's why they point-blank refused your request to make it public domain - so yeah, now you have to answer to me and my interpretation of what they wrote", with a smirk on his face.

The copyright notice helps potential employers find him.


By that logic, nothing you've compiled with GCC can be public domain, because you can't do whatever you want with GCC.

And anyway, that's missing the point. You only need libgcc when you're using GCC. You don't need a public-domain libgcc because a public-domain C compiler wouldn't depend on libgcc in the first place.


I'm no lawyer, but this scenario doesn't sound realistic.

No. A "written by xyz" and "released to the public domain" does exactly the same thing.


I have no idea what you are talking about. The resultant executable that I produce using gcc as a tool, and my own code for everything that actually gets fed into that, and linked in, is entirely public domain. Can you point to just one single line or one opcode or one character string in any of my executables that you believe is copyrighted.


Sure. Or equivalent.


I didn't claim to have a public domain C compiler. Only the C runtime library. And with the switch to soft float, a new thing became missing from my C runtime library. Hence my enquiry.


Exactly you're no lawyer. And nor are you every single judge in the world. And it is those who will decide. And I don't want the author to have any leg to stand on. As opposed to being the undisputed copyright holder, who has never agreed to relinquish copyright, and refuses point-blank to relinquish it.

It's not the same: copyright gives the author a way to legally enforce that their name stays on the code they wrote. There's no way to do that if the code is public domain.


Of course not. That's the entire point of GCC's runtime library exception: when you combine GCC's runtime code with your code, the combination uses the license of your code, and your code is public domain.


Then you need to hire a lawyer. There's no substitute for proper legal advice.