I understand the arguments.
It's worth remembering that coreboot has to date run on 5 different
architectures. 4 of those used paging. The x86 has always been the
outlier. Lack of paging has costs not discussed much. Rmodules would
be a lot simpler if we had paging. We could make the code space
re
Nice answer, Scott.
You pointed out everything I was going to say. I think this is
something we should put on the wiki in a FAQ. A 64bit ramstage has
questionable value, but a 64bit payload might be useful.
Marc
On Sun, Aug 10, 2014 at 4:20 PM, Scott Duplichan wrote:
> Vladimir 'φ-coder/phcode
Vladimir 'φ-coder/phcoder' Serbinenko [mailto:phco...@gmail.com] wrote"
]On 10.08.2014 21:06, John de la Garza wrote:
]> I understand that the calling functions in 32 bit C uses the stack and
]> this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use
]> registers to pass arguments t
Piotr Król wrote:
> Problem occurs at very early phase.
Hm.
> There is no coreboot gdb support
There is some gdb support in coreboot, but maybe not for ARM?
> so I used qemu '-s -S'. Whole qemu command:
>
> qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom
Is -kern
On Sun, Aug 10, 2014 at 02:35:46PM -0700, ron minnich wrote:
> You can't assume much of anything. That commit seems not that harmful.
> What would help is if you tell us more about when the problem happens.
> There's just not enough info in your note, but I'd love to try to
> help.
I will try to d
On Sun, Aug 10, 2014 at 2:48 PM, The Gluglug wrote:
> What about 32-bit-only machines, or people that want to use a 32-bit OS?
>
well, we won't compile 64-bit firmware for 32-bit machines, if that
helps. See: ARM v8 vs. v7.
And a 32-bit OS can run on a machine with 64-bit firmware; see: EFI.
r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What about 32-bit-only machines, or people that want to use a 32-bit OS?
On 10/08/14 22:37, ron minnich wrote:
> One of the reasons I"m working to implement paging for 32-bit mode
> is for our eventual change to 64-bit mode for coreboot. It's gone
>
One of the reasons I"m working to implement paging for 32-bit mode is
for our eventual change to 64-bit mode for coreboot. It's gone on the
back burner for a bit as I'm doing a few other coreboot things first.
I'd love to have the help, if you have time.
ron
On Sun, Aug 10, 2014 at 1:02 PM, Vla
You can't assume much of anything. That commit seems not that harmful.
What would help is if you tell us more about when the problem happens.
There's just not enough info in your note, but I'd love to try to
help.
Thanks!
ron
On Sun, Aug 10, 2014 at 12:57 PM, Piotr Król wrote:
> Hi all,
> I tri
On 10.08.2014 21:06, John de la Garza wrote:
> I understand that the calling functions in 32 bit C uses the stack and
> this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use
> registers to pass arguments to functions? If this is the case why not
> run in 64 bit mode?
>
> Also, eve
Hi all,
I tried to boot coreboot using latest qemu and figured out that it fails
with:
qemu: fatal: Trying to execute code outside RAM or ROM at 0x0400
R00=0002 R01= R02= R03=
R04= R05= R06= R07=
R08= R09= R10=000
Am 10.08.2014 um 21:06 schrieb John de la Garza:
> Doesn't 64 bit C use registers to pass arguments to functions? If
> this is the case why not run in 64 bit mode?
Even in 64bit mode you have to store state somewhere (that is, on the
stack) before you have free registers to call new functions.
I understand that the calling functions in 32 bit C uses the stack and
this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use
registers to pass arguments to functions? If this is the case why not
run in 64 bit mode?
Also, even if cache as RAM is used and a stack is available, why n
13 matches
Mail list logo
