>> >> I am told that AmlCode is defined as array of (unsigned) char in
>> >> some other file. Declaring it as some other type here is not
>> >> valid C, and *will* break with GCC, with some options (-combine
>> >> or LTO at least) -- it will not compile.
>> >
>> > The biggest worry for me is incor
>> >> -extern unsigned char AmlCode[];
>> >> +extern const acpi_header_t AmlCode;
>> > And we're positive, this always does the right thing with gcc?
>>
>> I am told that AmlCode is defined as array of (unsigned) char in
>> some other file. Declaring it as some other type here is not
>> valid C, a
> It seems like others must have this problem of needing to force a binary
> blob into a struct.
Just memcpy() it from the blob to the struct. If I remember your
code correctly, you copy it later anyway, so might as well do it
in one step.
Segher
--
coreboot mailing list: coreboot@coreboot.o
> On 3/24/10 11:02 PM, repository service wrote:
>> -extern unsigned char AmlCode[];
>> +extern const acpi_header_t AmlCode;
> And we're positive, this always does the right thing with gcc?
I am told that AmlCode is defined as array of (unsigned) char in
some other file. Declaring it as some othe
You don't need the -( -) here, FWIW. libgcc does not require
symbols
from
coreboot.a ;-)
Yes, actually it does. On powerpc libgcc uses external symbols
that it
does not provide.
Do you mean abort()?
Obviously.
Obvious to you perhaps, but not to me, that's why I asked :-)
Yeah, you nee
What happens to libgcc if someone compiles gcc with regparm=3?
Nothing. It doesn't matter how the compiler itself is compiled.
Will libgcc still be compiled with regparm=0?
Yes.
Segher
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I'm worried about any libgcc compiled with regparm!=0, but for
now this
patch improves the situation.
libgcc uses the default calling convention.
Is there an attribute to say "this function uses the default calling
convention no matter what CFLAGS we have right now"?
Sure, and you're alread
You don't need the -( -) here, FWIW. libgcc does not require symbols
from
coreboot.a ;-)
Yes, actually it does. On powerpc libgcc uses external symbols that it
does not provide.
Do you mean abort()? Yeah, you need to provide that yourself, on all
targets
(nothing special about PowerPC); the
I'm worried about any libgcc compiled with regparm!=0, but for now
this
patch improves the situation.
libgcc uses the default calling convention. The problem is that
the (implicit) calls to the routines in libgcc are done with the
-mregparm from the command line.
Segher
--
coreboot mailin
programs that are compiled with non-default regparm values are
miscompiled if they use libgcc.
This patch works around the problem for coreboot.
Please mention the GCC bugreport # in the source near every workaround;
that way, you can one day get rid of it. This is PR41055.
makerule coreboot
Okay, I understand the question now, I hope.
my understanding of all this is:
1. if you want it set a certain way, you have to set it
Yes.
2. don't ever assume it has any particular value.
For inline asm? Yes.
The ABI says that DF=0 whenever a function is called. For GCC, this
means tha
is the last test below with 0x1 (2^32) in the formula
guaranteed
to work or may cpp truncate the results to 32 bit? I'd rather avoid
introducing a test that can never trigger.
[There doesn't really exist anything called "cpp" anymore -- you mean
to say "the C preprocessor"].
#if CONFI
There's a warning in the man pages for gcc that says that you have to
compile all the functions (including libraries) with the same
setting.
It says that in the description of -mregparm, not of the function
attribute "regparm", and it is slightly misleading: -mregparm
specifies the default for
What about __attribute__((regparm(0))) ?
The gcc documentation is not clear on this, but a call made this way
should take all of its arguments from the stack.
Segher: How do regparm(0) and stdcall differ for i386?
"stdcall" means the callee pops the args from the stack when it returns;
"cdecl"
Can I have your Ack for it? You already checked in the makefile
portion
of it, so right now the tree won't compile for anyone besides you
and me.
Here, have mine:
Acked-by: Segher Boessenkool <[EMAIL PROTECTED]>
(I don't particularly like this script -- it requires bash i
- Segher needs to review which attributes globvars needs to not be
optimized away.
It doesn't need any: if it's used, it won't be optimised away;
and if it isn't used, who cares :-)
There could be an issue if you hid some facts from the compiler,
but you didn't.
The only remaining issue is, do
Don't calculate "flash_baseaddr" until the final value of "size"
is known, otherwise we end up trying to map a page right after
end of memory.
Fixes #112.
Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]>
Acked-by: Stefan Reinauer <[EMAIL PROTEC
if somebody has tested this, and it looks good to me, I'll ack it. Do
we have one test? I know you were discussing it on IRC.
The reporter of the bug tested it, and it fixed the problem.
So, _does_ it look good to you? ;-)
Segher
--
coreboot mailing list
coreboot@coreboot.org
http://www.co
Don't calculate "flash_baseaddr" until the final value of "size"
is known, otherwise we end up trying to map a page right after
end of memory.
Fixes #112.
Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]>
---
flashrom.c | 16
1 files change
Don't APs also need to initialize DRAM? Or can the BSP do this
"remotely" ?
APs should do it.
I'm getting a supermicro mainboard with 4 sockets and 128 GB memory,
and I want that done in parallel :-)
In principle, the BSP can initialise multiple memory controllers
in parallel as well. Using
The v3 version was heavily adapted and it does work nice in cross
compile environments already.
Are you sure there is a benefit of updating it?
The benefit of frequently updating to new versions of foreign code
is that when you don't, you will have a really hard time updating
later when you _do_
"There are many ways to get code into the EFI environment. An attacker
can modify the bootlader directly, modify bootloader varibles in
NVRAM, modify and reflash firmware or exploit an implementation flaw
in the driver.
Nothing specific to EFI here, as far as I can see. All of this is
true as w
In any case, I hope we can all agree that certainly nothing in the PCI
spec requires all devices on a mainboard to have the same subsystem
(vendor) ID (some might not even have that register implmented!)
Yes it is an optional field.
Since version 2.2 of the PCI spec, it is required on most cla
In practice the subsystem vendor IDs are quite arbitrary and
definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a
mainboard:
the subsystem IDs should uniquely identify the device, without having
to look at the "regular" IDs as w
Section 6.2.4 of the PCI specification states:
These registers are used to uniquely identify the add-in card or
subsystem
where the PCI device resides. The provide a mechanism for add-in
card vendors to
distinguish their add-in cards from one another even though the
add-in cards may
have the
In practice the subsystem vendor IDs are quite arbitrary and
definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard:
the subsystem IDs should uniquely identify the device, without having
to look at the "regular" IDs as wel
The subsystem IDs roughly identify the PCB a component sits on. So
unless you have multiple pluggable boards in a system there should
only be one subsystem vendor and one subsystem device id.
I agree with Eric here. I question the need for subsystem IDs in the
first
place. Is there a particula
> I agree to veto the vote. Hare's good enough for me.
I didn't say that!
Segher
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
> Let's get a decision on this. Do we vote?
Sure, why not. Or we can just agree to agree, veto the veto,
so we don't have to vote for a vote? :-)
Segher
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
>> 6) Much of the U-Boot code, especially its device drivers come
>> from the corresponding device drivers in the Linux kernel.
>
> There's no need for "drivers" in LB, that's the whole point.
Well, you need minimal drivers for your boot devices. You can put
them in a separate payload file, whi
> 3) Das U-Boot had a very early name change from PPCBoot when it
>added non-PPC processor support. LinuxBIOS had a recent name
>change to coreboot, but that was a huge mistake.
Not really. There were good reasons to change the name. Yes, of
course not-heavily-involved people have to be
> Dumb question: Does this break strict aliasing in any way?
Show the code? I'll do you an analysis.
Segher
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
> We are of course free to go away from the ePAPR flat device tree (we
> did already to some extent).
I am not talking about the ePAPR flat tree. I am talking about the
flat tree as used in PowerPC Linux for many years now.
> I agree with Segher we should stay close to the "original". That's wh
> @ in this case seperates the type of resources (pci) from the instance
> of it (device, function).
>
> So @ is a seperator. Using _ will add ambiguity as it is NOT a
> seperator. same problem for -.
>
> Stepan, will the OFW guys kill us if we allow ':' as well as @.
The general syntax of a pathn
> In the future, I'll add an explicit "if you think you see anything that
> looks like an error message, STOP IMMEDIATELY" to any mails with
> subversion commands.
That, or "if you see any subversion command, STOP IMMEDIATELY".
:-)
Segher
--
coreboot mailing list
coreboot@coreboot.org
http:/
35 matches
Mail list logo
