On 15 April 2014 13:52, Leif Lindholm leif.lindholm@linaro.org wrote:
On 15 April 2014 12:09, Ryan Harkin ryan.harkin@linaro.org wrote:
I'm abandoned this change. But I don't think this problem is over yet...
I'm sure it's not :]
It would be helpful to have a bit of background on how the difference between bare metal and glibc toolchain causes this particular issue.
Yes, it would :-/
I haven't a clue how it causes it, I only know that it happens.
So, dead from reset?
Not quite. It gives some garbage on the serial terminal and then nothing happens. I was hoping it was only serial corruption and that the boot countdown would run and boot the kernel, but nope, I just get a load of garbage on the terminal.
Perhaps even push back a bit? I mean, what ffs is the point of, for instance, defining uint32_t as 'unsigned int' on glibc for arm32 and 'unsigned long' on bare metal for arm32. If these things are causing us grief, we should report them to the toolchain group as bugs.
I agree: why must the types be different. I understand the libraries and function call being different, but type sizes should be fixed. How on
earth
do we cope with that?? But whether it's a bug or a feature is a
different
matter.
If we do come across anything like this, we should be able to script this in the BaseTools. "Somehow." UEFI still has its own definitions for _all_ data types - so the actual source should be safe. The issue you're seeing may be due to some
... assembly language? like a rogue "w" instead of "x" in a register move? That's one of Tixy's ideas when I was sounding this out with him earlier.
We must not cripple this reality by trying to conform to an idealistic fantasy.
I think the problem is deeper than this. The real world you talk about
is
the current reality, where we are depending on UEFI and the kernel being built with the same toolchain and where we build them ourselves.
The other real world is one where UEFI will be provided by the vendor and the kernel by a distro. Neither of which will be under our control or
build
environment. So depending on the toolchain to sort this stuff out isn't going to fly, surely? I'm glad it's not my problem to sort out ;-)
I'm not. So it may well be worth setting up CI jobs building with bare-metal too. And adding a command line option for "toolchain profiles".
Imagine what happens when a BIOS vendor builds UEFI using the ARM
compiler.
Or, more likely: a Microsoft compiler.
Indeed.
So ... could you raise a defect on the issue you've seen?
Sure. Were you thinking a launchpad bug, or raising with ARM? Or even
one
of those JIRA things in the Landing Team space?
Yeah - linaro-uefi. Ilias promised to set up some sort of defect review - so we can go through it then and decide whether we report it to ARM or not.
Ok, will do.
At the moment, the platform I am working on is using a binary build of
UEFI
supplied by ARM; that's the only one that works. I have no control over what toolchain that's built with, of course. This is my alternate
reality.
Yeah, I feel your pain. So, I assume this is a release blocker for you. All platforms?
No, it's not all that serious so far: I don't need to build my own UEFI for this new platform just yet. The binary version from ARM works fine for now. The other platforms, including 64 bit models, are all working fine today with the linux-gnu toolchain.
It would be nice to be able to build UEFI for the hwpacks though, so I can set a sensible default config and so on.
/ Leif