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