If I use a default config for i440fx/piix4, building a 16MB ROM works
fine, but 32MB or 64MB doesn't work anymore:
...
CC postcar/southbridge/intel/common/rtc.o
LINK cbfs/fallback/postcar.debug
OBJCOPYcbfs/fallback/romstage.elf
CREATE build/mainboard/emulation
Hi,
I'm currently trying to enable vboot on qemu. I did the configuration
and using the fmd file "vboot-rwa-16M.fmd" from subdir qemu-i440fx , but
getting an error message like
VBOOT: Loading verstage.
Cannot locate primary CBFS
I also tried to build the 4.13 release, but the result is the s
Dear Furquan, dear Aaron,
Commit 3b02006afe (device: Enable resource allocator to use multiple
ranges) [1] also breaks the qemu-i440fx, that SeaBIOS does not show any
graphics. Please find the logs attached.
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/39486
$ qemu-sy
Hi I am a second year student pursuing computer science and applied
mathematics at IIIT-Delhi, India. I was building libpayload when I ran into
some errors.
>CC libpci/libpci.libpci.o
>make: MMD: No such file or directory
>AR build/libpci.a
>make: rc: No such file or directory
>make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Disabled for now. There might be a disk space issue affecting this
particular emulation target, looking into it.
Sorry for the noise!
On 02/12/2018 02:55 AM, Paul Menzel wrote:
> Dear Timothy,
>
>
> Am Samstag, den 10.02.2018, 18:32 -0600 schrieb
Dear Timothy,
Am Samstag, den 10.02.2018, 18:32 -0600 schrieb REACTS:
> The QEMU x86_64 Q35 fails verification for branch master as of commit
> 1b64ae1119fc7891b043d5d29bf93859ef9dbfa1
>
> The following tests failed:
> BOOT_FAILURE
>
> Commits since last successful test:
> 1b64ae1 soc/intel/ca
The QEMU x86_64 Q35 fails verification for branch master as of commit
3be35976d6a640d0bc4fd40e232b6499b170431f
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
3be3597 google/snappy: enhance BigDaddy USB#2 2.0 strength
1b64ae1 soc/intel/cannonlake: Add Pch iSCLK progr
The QEMU x86_64 Q35 fails verification for branch master as of commit
1b64ae1119fc7891b043d5d29bf93859ef9dbfa1
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
1b64ae1 soc/intel/cannonlake: Add Pch iSCLK programming
106a9fe mb/google/fizz: Set SATA GPIOs in bootblock
The QEMU x86_64 Q35 fails verification for branch master as of commit
6ee716e863117246d453e573d1a128da28b62cb7
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
6ee716e drivers/intel/fsp2_0: Remove fsp_find_smbios_memory_info() from FSP2.0
driver
93fde11 soc/intel/can
The QEMU x86_64 Q35 fails verification for branch master as of commit
2a9e8124e19a1a9143b9461d1f1f114e8e751c8a
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
2a9e812 mb/google/fizz: Set Pmax to 120 for all SKUs
dc4bc06 google/kahlee/grunt: Fix 2 device specific vari
The QEMU x86_64 Q35 fails verification for branch master as of commit
485c0ad0783aa168feab8944e498a393774512fd
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
485c0ad0 inteltool: Add Cougar- and Pantherpoint PCH PCI IDs for SPI
921fa84 inteltool: Fix displaying 64bit
ingegneriafore...@alice.it wrote:
> atp-get install qemu
>
> to install qemu on my Ubuntu 16.04 PC. Is it right ?
Probably, yes.
> For coreboot i need to use qemu-sh4 ?
No, the coreboot qemu target is for x86.
Use either qemu-system-i386 or qemu-system-x86_64. Maybe only the
firs
On Fri, Aug 04, 2017 at 04:17:29PM +, ron minnich wrote:
> Sorry, don't know what sh4 is ...
>
Some kind of architecture... (https://en.wikipedia.org/wiki/SuperH#SH-4)
>
>
> On Fri, Aug 4, 2017 at 9:09 AM ingegneriafore...@alice.it <
> ingegneriafore...@alice.it> wrote:
>
> > Hello everybo
Sorry, don't know what sh4 is ...
On Fri, Aug 4, 2017 at 9:09 AM ingegneriafore...@alice.it <
ingegneriafore...@alice.it> wrote:
> Hello everybody,
>
>
> I've used
>
> atp-get install qemu
>
> to install qemu on my Ubuntu 16.04 PC. Is it right ?
>
> Now i have several qemu file in /usr/bin.
>
>
Hello everybody,
I've used
atp-get install qemu
to install qemu on my Ubuntu 16.04 PC. Is it right ?
Now i have several qemu file in /usr/bin.
For coreboot i need to use qemu-sh4 ?
Is it right the command that i found on the coreboot wiki
$ qemu -bios path/to/coreboot.rom -h
Hi,
I'm trying to get coreboot working with QEMU x86 q36/ich9 but it
is hanging at grub prompt. With coreboot compiled for i440fx/pii4 and '-M pc'
on the qemu command this works fine. Also native SeaBIOS works with
q35 option no problem.
So I'm wondering if anyone has this working. Maybe I'm just
Hi Daoud,
This page might help:
https://www.coreboot.org/Lesson1
Martin
On Thu, Apr 14, 2016 at 2:24 AM, Gerd Hoffmann wrote:
> On Do, 2016-04-14 at 10:01 +0200, daoud yessine wrote:
>> What should I tap to run qemu with coreboot ?
>
> CONFIG_VENDOR_EMULATION=y
> CONFIG_BOARD_EMULATION_QEMU_X
On Do, 2016-04-14 at 10:01 +0200, daoud yessine wrote:
> What should I tap to run qemu with coreboot ?
CONFIG_VENDOR_EMULATION=y
CONFIG_BOARD_EMULATION_QEMU_X86_I440FX=y
(for -M q35 you need CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y instead).
> And Is there a graphical option to activate in qemu ?
What should I tap to run qemu with coreboot ?
And Is there a graphical option to activate in qemu ?
thanks
ᐧ
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2016 01:58 AM, Paul Menzel wrote:
> Dear coreboot folks,
>
>
> Am Donnerstag, den 10.03.2016, 19:24 -0600 schrieb REACTS:
>> The QEMU x86_64 Q35 fails verification for branch master as of
>> commit
>>
>> The following tests failed:
>> BOOT_
Dear coreboot folks,
Am Donnerstag, den 10.03.2016, 19:24 -0600 schrieb REACTS:
> The QEMU x86_64 Q35 fails verification for branch master as of
> commit
>
> The following tests failed:
> BOOT_FAILURE
>
> Commits since last successful test:
> c7a1a3e northbridge/i945/gma: Re-enable NVRAM tft_b
The QEMU x86_64 Q35 fails verification for branch master as of commit
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
c7a1a3e northbridge/i945/gma: Re-enable NVRAM tft_brightness
a2176d8 soc/apollolake: Add memory and reserve MMIO resources
555d6c2 cbmem: Add utility
Dear all:
I can boot in Linux with default machine use :
qemu-system-x86_64 -bios [ Path to coreboot with FILO ] -hda [ Path to
Linux image ] -nographic
when I use Q35 machine :
qemu-system-x86_64 *-M q35* -bios [ Path to coreboot with FILO ] -hda [
Path to Linux image ] -nographic
the FILO would
Dear Tyler,
Am Freitag, den 19.06.2015, 20:58 -0700 schrieb Tyler Parks:
> I'm using Fedora 20 x86_64, along with freshly pulled Coreboot source,
> and trying to compile Coreboot for QEMU.
Welcome to coreboot!
> However I get a make error that says CBFS files located outside
> itself. I haven'
On 05/13/2015 12:31 PM, Timothy Pearson wrote:
On 05/13/2015 09:56 AM, Aaron Durbin via coreboot wrote:
On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin wrote:
All those are empty including dmesg. Was this a flaky test run?
Yes it was, and of course it happened overnight. I was testing a
differ
On 05/13/2015 09:56 AM, Aaron Durbin via coreboot wrote:
On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin wrote:
On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
Test Stand wrote:
The QEMU x86_64 Q35 fails verification as of commit
0a50d9b35334d03f13b38e21497ba0aae8b16712
On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin wrote:
> On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
> Test Stand wrote:
>> The QEMU x86_64 Q35 fails verification as of commit
>> 0a50d9b35334d03f13b38e21497ba0aae8b16712
>>
>> The following tests failed:
>> ACPI_DSDT_ACCE
On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot
Test Stand wrote:
> The QEMU x86_64 Q35 fails verification as of commit
> 0a50d9b35334d03f13b38e21497ba0aae8b16712
>
> The following tests failed:
> ACPI_DSDT_ACCESS_FAILURE
> ACPI_SSDT_ACCESS_FAILURE
> DMIDECODE_ACCESS_FAILUR
The QEMU x86_64 Q35 fails verification as of commit
0a50d9b35334d03f13b38e21497ba0aae8b16712
The following tests failed:
ACPI_DSDT_ACCESS_FAILURE
ACPI_SSDT_ACCESS_FAILURE
DMIDECODE_ACCESS_FAILURE
CBMEM_CONSOLE_ACCESS_FAILURE
CBMEM_TIMESTAMP_ACCESS_FAILURE
CBMEM_OBJECT_TABLE_ACCESS_FAILURE
Commit
On 05/06/2015 12:05 PM, Aaron Durbin wrote:
On Wed, May 6, 2015 at 9:54 AM, Aaron Durbin wrote:
On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson
wrote:
On 05/06/2015 11:46 AM, Aaron Durbin wrote:
On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
wrote:
On 05/06/2015 11:41 AM, Aaron Durbi
On Wed, May 6, 2015 at 9:54 AM, Aaron Durbin wrote:
> On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson
> wrote:
>> On 05/06/2015 11:46 AM, Aaron Durbin wrote:
>>>
>>> On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
>>> wrote:
On 05/06/2015 11:41 AM, Aaron Durbin wrote:
>
>
On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson
wrote:
> On 05/06/2015 11:46 AM, Aaron Durbin wrote:
>>
>> On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
>> wrote:
>>>
>>> On 05/06/2015 11:41 AM, Aaron Durbin wrote:
That's probably my fault. I was under the impression monotonic_t
On 05/06/2015 11:46 AM, Aaron Durbin wrote:
On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
wrote:
On 05/06/2015 11:41 AM, Aaron Durbin wrote:
That's probably my fault. I was under the impression monotonic_timer
was a first class citizen now (I at least recall someone doing that) I
thought w
On 05/06/2015 11:45 AM, Aaron Durbin wrote:
On Wed, May 6, 2015 at 9:41 AM, Aaron Durbin wrote:
I see the error in your original email...
coreboot/src/lib/timestamp.c:184: undefined reference to `timer_monotonic_get'
Does your qemu build have a timestamp_get() defined?
I'm not sure. The fa
On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson
wrote:
> On 05/06/2015 11:41 AM, Aaron Durbin wrote:
>>
>> That's probably my fault. I was under the impression monotonic_timer
>> was a first class citizen now (I at least recall someone doing that) I
>> thought wrong?
>>
>> You could add the follow
On 05/06/2015 11:41 AM, Aaron Durbin wrote:
That's probably my fault. I was under the impression monotonic_timer
was a first class citizen now (I at least recall someone doing that) I
thought wrong?
You could add the following in the beginning of that function:
if (!IS_ENABLED(CONFIG_HAVE_MONOT
On Wed, May 6, 2015 at 9:41 AM, Aaron Durbin wrote:
> On Wed, May 6, 2015 at 9:36 AM, Timothy Pearson
> wrote:
>> On 05/06/2015 06:54 AM, Patrick Georgi wrote:
>>>
>>> 2015-05-05 21:49 GMT+02:00 Timothy
>>> Pearson:
While working on the test system earlier today I noticed that QEMU buil
On Wed, May 6, 2015 at 9:36 AM, Timothy Pearson
wrote:
> On 05/06/2015 06:54 AM, Patrick Georgi wrote:
>>
>> 2015-05-05 21:49 GMT+02:00 Timothy
>> Pearson:
>>>
>>> While working on the test system earlier today I noticed that QEMU builds
>>> are currently failing with the following error:
>>>
>>>
On 05/06/2015 06:54 AM, Patrick Georgi wrote:
2015-05-05 21:49 GMT+02:00 Timothy Pearson:
While working on the test system earlier today I noticed that QEMU builds
are currently failing with the following error:
coreboot/src/lib/timestamp.c:184: undefined reference to
`timer_monotonic_get'
Bui
2015-05-05 21:49 GMT+02:00 Timothy Pearson :
> While working on the test system earlier today I noticed that QEMU builds
> are currently failing with the following error:
>
> coreboot/src/lib/timestamp.c:184: undefined reference to
> `timer_monotonic_get'
>
> Builds using the same configuration wer
All,
While working on the test system earlier today I noticed that QEMU
builds are currently failing with the following error:
coreboot/src/lib/timestamp.c:184: undefined reference to
`timer_monotonic_get'
Builds using the same configuration were working yesterday. The
KFSN4-DRE does not
The QEMU x86_64 Q35 fails verification as of commit
8ccdeaeb207031eea3881511acfaf3e949678f74
The following tests failed:
CBMEM_TIMESTAMP_ACCESS_FAILURE
CBMEM_OBJECT_TABLE_TRUNCATED
Commits since last successful test:
8ccdeae haswell: Link stage_cache_external_region into ramstage, too
634899c re
On 05/04/2015 10:08 PM, Raptor Engineering Automated Test Stand wrote:
The QEMU x86_64 Q35 fails verification as of commit
8ccdeaeb207031eea3881511acfaf3e949678f74
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
8ccdeae haswell: Link stage_cache_external_region int
The QEMU x86_64 Q35 fails verification as of commit
8ccdeaeb207031eea3881511acfaf3e949678f74
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
8ccdeae haswell: Link stage_cache_external_region into ramstage, too
634899c resource: Adjust memory resources high earlier
e6
The QEMU x86_64 Q35 fails verification as of commit
58649b058baecf24a07a2bc85fff68b339d67503
The following tests failed:
CBMEM_TIMESTAMP_ACCESS_FAILURE
CBMEM_OBJECT_TABLE_TRUNCATED
Commits since last successful test:
See attached boot log for details
This message was automatically generated f
The QEMU x86_64 Q35 fails verification as of commit
6897f4e796c4645cec5d7a247dba78f002008080
The following tests failed:
CBMEM_TIMESTAMP_ACCESS_FAILURE
CBMEM_CONSOLE_CONTENT_TRUNCATED
Commits since last successful test:
6897f4e google/storm: indicate start of normal boot on LED ring
ace3e3f i2c/
On 04/22/2015 01:28 AM, Gerd Hoffmann wrote:
Hi,
If the community would like me to stop sending these notifications I
will do so; I could also adjust the maximum frequency if desired.
How about sending out messages on status changes (i.e. edge not level
triggered). That should avoid annoy
Hi,
> If the community would like me to stop sending these notifications I
> will do so; I could also adjust the maximum frequency if desired.
How about sending out messages on status changes (i.e. edge not level
triggered). That should avoid annoying repeated reports on the same
failure.
Al
On 22.04.2015 06:01, Timothy Pearson wrote:
> On 04/21/2015 05:25 PM, Carl-Daniel Hailfinger wrote:
>> Thank you for providing this service. It is very much appreciated.
>>
>> I would like to make a suggestion, though: The mail size of failure
>> reports is increasing constantly as long as a boot p
On 04/21/2015 05:25 PM, Carl-Daniel Hailfinger wrote:
Thank you for providing this service. It is very much appreciated.
I would like to make a suggestion, though: The mail size of failure
reports is increasing constantly as long as a boot problem remains
unfixed. Would it make sense to only lis
On 21.04.2015 19:14, Timothy Pearson wrote:
> On 04/21/2015 11:44 AM, Timothy Pearson wrote:
>> On 04/21/2015 11:31 AM, Patrick Georgi via coreboot wrote:
>>> 2015-04-21 17:31 GMT+02:00 Gregg Levine:
I suspect somehow it was supposed to be internal to hs outfit only.
>>> Timothy provides boot
On 04/21/2015 11:44 AM, Timothy Pearson wrote:
On 04/21/2015 11:31 AM, Patrick Georgi via coreboot wrote:
2015-04-21 17:31 GMT+02:00 Gregg Levine:
I suspect somehow it was supposed to be internal to hs outfit only.
Timothy provides boot testing of coreboot master with QEmu and a AMD
board that
On 04/21/2015 11:31 AM, Patrick Georgi via coreboot wrote:
2015-04-21 17:31 GMT+02:00 Gregg Levine:
I suspect somehow it was supposed to be internal to hs outfit only.
Timothy provides boot testing of coreboot master with QEmu and a AMD
board that he maintains as a service to the community.
A
2015-04-21 17:31 GMT+02:00 Gregg Levine :
> I suspect somehow it was supposed to be internal to hs outfit only.
Timothy provides boot testing of coreboot master with QEmu and a AMD
board that he maintains as a service to the community.
> And something changed with regards to the logic behind how t
The QEMU x86_64 Q35 fails verification as of commit
1abb6002ddc84dd6f2dc01e76475480445fa4271
Commits since last successful test:
1abb600 broadcom/cygnus: Fix missing writel->write32 transformation
7ab46f8 libpayload: add timer driver for cygnus
b048432 cygnus: add QSPI driver
82a7bc4 veyron: add
Hello!
My thoughts exactly. Thank you sir.
I suspect somehow it was supposed to be internal to hs outfit only.
And something changed with regards to the logic behind how those
annoying e-mail messages being sent to us.
As for the test cases, they are extremely confusing to me. How many of
us also
On Di, 2015-04-21 at 02:24 -0500, Raptor Engineering Automated Test
Stand wrote:
> The QEMU x86_64 Q35 fails verification as of commit
> 7ab46f8085146db57699001462da871f2e4d9965
Log says at the end "RAPTOR ENGINEERING AUTOMATED TEST BOOT SUCCESS"
Can you fix your test case and stop spamming the
The QEMU x86_64 Q35 fails verification as of commit
7ab46f8085146db57699001462da871f2e4d9965
Commits since last successful test:
7ab46f8 libpayload: add timer driver for cygnus
b048432 cygnus: add QSPI driver
82a7bc4 veyron: add new SDRAM configuration with ram-code 1101b
823f607 pistachio: Remov
The QEMU x86_64 Q35 fails verification as of commit
4038a7f631dce05aa184184a225a49bc7723aed0
Commits since last successful test:
4038a7f gigabyte/ga-b75m-d3v: Add GIGABYTE GA-B75M-D3V mainboard
31ca97c southbridge/intel/bd82x6x: Add LPC id 0x1e49 for B75 chipset
bcff3bd mainboard/lenovo/t430s,t53
The QEMU x86_64 Q35 fails verification as of commit
f21b657f27965beacd2a3134aafbf66d4db60930
Commits since last successful test:
f21b657 build system: improve portability by not relying on extraordinary dd
options
01368ed Kconfig: rename CONSOLE_SERIAL_UART to DRIVERS_UART
c047b10 purin: add ns1
The QEMU x86_64 Q35 fails verification as of commit
f21b657f27965beacd2a3134aafbf66d4db60930
Commits since last successful test:
f21b657 build system: improve portability by not relying on extraordinary dd
options 01368ed Kconfig: rename CONSOLE_SERIAL_UART to DRIVERS_UART c047b10
purin: add ns
The QEMU x86_64 Q35 does not boot as of commit
c14e42623bede2480284cf500362d545f85f8f69
Commits since last successful test:
See attached boot log for details
This message was automatically generated from Raptor Engineering's QEMU x86_64
Q35 test stand
Raptor Engineering offers coreboot consul
Dear Ajoy,
welcome to coreboot!
Am Dienstag, den 07.04.2015, 20:56 +0530 schrieb Ajoy Das:
> I am running coreboot on qemu with the following sequence.
>
> coreboot -> seabios -> GRUB -> kernel.
>
> The kernel booting hangs at *All ACPI Tables successfully acquired*
>
> coreboot-4.0
Please
On Sat, Aug 16, 2014 at 01:15:05PM -0700, ron minnich wrote:
> The ROMSTAGE on ARM is expected to be SRAM. When you know the SRAM
> address for a given mainboard, you need to set it up in Kconfig for
> *just* that mainboard.
>
> Nice work, I think you're getting close!
Thanks :)
Meanwhile I was a
The ROMSTAGE on ARM is expected to be SRAM. When you know the SRAM
address for a given mainboard, you need to set it up in Kconfig for
*just* that mainboard.
Nice work, I think you're getting close!
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/cor
Hi all,
during debugging of qemu-armv7 I found that coreboot performs memcpy to
ROMSTAGE_BASE area. This is in src/arch/armv7/memcpy.S:
3: PLD(pld [r1, #124] )
4: ldr8w r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
subsr2, r2, #32
On Mon, Aug 11, 2014 at 04:00:19PM -0700, ron minnich wrote:
During debugging I found that stack is initialized in range
0x4-0x7FF00 (using .Stack and .Stack_size).
When coreboot code is executed:
reset
init_stack_loop
call_bootblock
main
+- armv7_invalidate_caches
+- icache_invalidate_all
On Tue, Aug 12, 2014 at 05:30:03AM +0200, Patrick Georgi wrote:
> Am 12.08.2014 um 00:37 schrieb Piotr Król:
> > Anyone know how to load bootblock debug symbols to gdb when debugging
> > using '-s -S' option ?
> add-symbol-file $filename $loadaddr
When I try:
gdb$ target remote :1234
Remote debug
On Mon, Aug 11, 2014 at 04:00:19PM -0700, ron minnich wrote:
> Sorry, in other words, how much ROM are you setting up on that qemu
> board? The 'execute outside ram or rom' is usually a jump to an IP
> that qemu does not recognize as ROM/RAM.
ROM is probably represented in vexpress-a9 as vexpress.
Am 12.08.2014 um 00:37 schrieb Piotr Król:
> Anyone know how to load bootblock debug symbols to gdb when debugging
> using '-s -S' option ?
add-symbol-file $filename $loadaddr
Patrick
signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://w
Sorry, in other words, how much ROM are you setting up on that qemu
board? The 'execute outside ram or rom' is usually a jump to an IP
that qemu does not recognize as ROM/RAM.
I suspect our emulator is assuming SRAM in there somewhere, can you
check? Certainly we depend on SRAM on the real hardwar
So what this is saying is that we expect the ROM for coreboot to start
at 64K. I hope this makes sense to you. Does this conflict with some
qemu expectation, do you know?
ron
On Mon, Aug 11, 2014 at 3:37 PM, Piotr Król wrote:
> On Mon, Aug 11, 2014 at 01:51:16PM -0700, ron minnich wrote:
>> I ca
On Mon, Aug 11, 2014 at 01:51:16PM -0700, ron minnich wrote:
> I can't recall for ARM, it's been more than a year since I used qemu
> on that platform. That said, ... on the platforms we use ROM is in low
> memory. What's your coreboot system.map say?
>
I'm not sure what 'coreboot system.map' is b
I can't recall for ARM, it's been more than a year since I used qemu
on that platform. That said, ... on the platforms we use ROM is in low
memory. What's your coreboot system.map say?
ron
On Mon, Aug 11, 2014 at 1:11 PM, Piotr Król wrote:
> On Mon, Aug 11, 2014 at 07:36:42AM -0700, ron minnich
On Mon, Aug 11, 2014 at 07:36:42AM -0700, ron minnich wrote:
> So, if you comment that one line out, do things work for you? Just
> double checking.
Comment is not enough to make it work. VE_NORFLASHALIAS has to be -1, then it
works for me. So patch for QEMU is:
diff --git a/hw/arm/vexpress.c b/h
So, if you comment that one line out, do things work for you? Just
double checking.
ron
On Mon, Aug 11, 2014 at 2:09 AM, Piotr Król wrote:
> On Mon, Aug 11, 2014 at 12:15:32AM +0200, Peter Stuge wrote:
>> > There is no coreboot gdb support
>>
>> There is some gdb support in coreboot, but maybe n
On Mon, Aug 11, 2014 at 12:15:32AM +0200, Peter Stuge wrote:
> > There is no coreboot gdb support
>
> There is some gdb support in coreboot, but maybe not for ARM?
What I tried to say is that it happens to early to connect to coreboot
using gdb support, but maybe I'm wrong.
>
> > so I used qemu '
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
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
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
@ron: please provide more information about your qemu: version, how
built, options, patches,... Try -M pc-q35-1.7 and -M pc-i440fx-1.7. Try
specifying --no-kvm and --enable-kvm. Speyifying -cpu may help as well.
From my experience with GRUB, qemu has following flaws:
- From version to version they
ron minnich wrote:
> I did a clean checkout again, crossgcc again, and it all works now.
Now you get to debug it. :p
Compare the images, compare object files, compile .xcompiles, maybe
try building again swapping the .xcompile, and so on.
Or, you can skip the debugging now that it works - then w
I did a clean checkout again, crossgcc again, and it all works now. I'm
flummoxed.
ron
On Sun, Mar 9, 2014 at 9:13 PM, David Hubbard <
david.c.hubbard+coreb...@gmail.com> wrote:
> On Sunday, March 09, 2014 08:26:05 PM you wrote:
> > On Sunday, March 09, 2014 05:14:51 PM you wrote:
> > > Story s
On Sunday, March 09, 2014 08:26:05 PM you wrote:
> On Sunday, March 09, 2014 05:14:51 PM you wrote:
> > Story so far:
> >
> > 1. pick q35 chipset
> > 2. qemu -M q35 etc. etc.
>
> $ qemu-system-i386 -M q35 --bios build/coreboot.rom
>
> -ENOREPRODUCE
>
> > 1. pick i440fx chipset.
> > 2. qemu -M pc et
This was supposed to go to the list, not Ron alone.
On Sunday, March 09, 2014 08:26:05 PM you wrote:
> On Sunday, March 09, 2014 05:14:51 PM you wrote:
> > Story so far:
> >
> > 1. pick q35 chipset
> > 2. qemu -M q35 etc. etc.
>
> $ qemu-system-i386 -M q35 --bios build/coreboot.rom
>
> -ENOREPR
Story so far:
1. pick q35 chipset
2. qemu -M q35 etc. etc.
1. pick i440fx chipset.
2. qemu -M pc etc. etc.
Endless repetitions of
qemu: unsupported keyboard cmd cmd=0x00
or 0x80
This is with crossgcc.
I'm disappointed it's this fragile. I'm worried that feature push has
gotten ahead of reliabil
Ah, if only that had worked, but it did not. Still blows up when trying to
load ramstage or when it enters ramstage.
ron
On Sat, Mar 8, 2014 at 11:22 PM, mrnuke wrote:
> On Saturday, March 08, 2014 10:30:51 PM ron minnich wrote:
>
> > q35 chipset. That's the only change I make.
>
> > qemu-sys
On Saturday, March 08, 2014 10:30:51 PM ron minnich wrote:
> q35 chipset. That's the only change I make.
> qemu-system-x86_64 --bios build/coreboot.rom -cdrom tinycore.iso -boot d
>
+ -M q35
There, I fixed it for you!
Alex
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.
I'm trying to do something very trivial and it fails badly.
Clean checkout. Make menuconfig. Select emulation, and the q35 chipset.
That's the only change I make. All else is default. I note that native vga
is selected by various Kconfigs.
Build crosstools.
Then build coreboot. The standard make
hi,
I want to boot qemu with coreboot.
the disk image use grub to load linux.
but I got errors in write_coreboot_table()
how to deal with it?
the following msg is the wrong log. the attachment is the whole log.
thank you!
SMBIOS tables: 370 bytes.
Adding CBMEM entry as no. 4
Writing high table for
Start with "QEMU Build Tutorial" http://www.coreboot.org/QEMU_Build_Tutorial
Unfortunately, that write up is sketchy and certainly not newbie-proof.
For instance, Tutorial does not point out that, of course, you do need
to build coreboot BIOS for the Qemu virtual machine (Emulator), not your
Would someone post step-by-step instructions for building coreboot for
QEMU and then starting QEMU? I keep getting problems like this:
Multiboot Information structure has been written.
0. FREE SPACE 07fe9c00 00016400
1. GDT07fe0200 0200
2. IRQ TABLE 07fe0400 1000
3. SMBIO
Dan Connelly wrote:
> Set maximal debugging for coreboot and build the coreboot.rom (with a
> few adjustments for gcc-4.6.3).
Sounds good so far.
> qemu-system-x86_64 -bios build/coreboot.rom -nographic
Sorry, no. You can't test coreboot built for one machine (your sunw)
on another machine (qem
Yes, I do have a lot of reading to do (per Peter's comment). But I am bashing
ahead, none the less.
I cloned the Tyan s2885 mainboard as Sunw k85ae. (Both AMD k8 with same
North/South.)
The superio on the k85ae is different from the s2885. I hacked out the Winbond
w83627hf and hacked in
When I build a 1024-kB Coreboot image (emulation/qemu-x86 mainboard),
qemu goes into a loop, resetting just after the "Jumping to boot code"
message. This can be avoided by removing the "| IO_MEM_ROM" from the
call to cpu_register_physical_memory(0x10 - isa_bios_size, ...)
call in pc_memory_in
On 5/2/10 6:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 5/2/10 5:00 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>
>>> Hello, when testing on QEMU I noticed that it always assumed 64 MiB RAM.
>>> Fix attached. Tested from 16 MiB to 2047 MiB
>>>
>>>
> Signed-off-by: Valdim
Stefan Reinauer wrote:
> On 5/2/10 5:00 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Hello, when testing on QEMU I noticed that it always assumed 64 MiB RAM.
>> Fix attached. Tested from 16 MiB to 2047 MiB
>>
>>
> Hi Vladimir,
>
> please sign off your patch so we can commit it:
>
> http:/
On 5/2/10 5:00 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Hello, when testing on QEMU I noticed that it always assumed 64 MiB RAM.
> Fix attached. Tested from 16 MiB to 2047 MiB
>
>
Hi Vladimir,
please sign off your patch so we can commit it:
http://www.coreboot.org/Development_Guideli
Hello, when testing on QEMU I noticed that it always assumed 64 MiB RAM.
Fix attached. Tested from 16 MiB to 2047 MiB
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== modified file 'src/mainboard/emulation/qemu-x86/northbridge.c'
--- src/mainboard/emulation/qemu-x86/northbridge.c 2010-04-08
1 - 100 of 182 matches
Mail list logo
