#95: Run coreboot in VirtualBox
---------------------------------+------------------------------------------
Reporter: uwe | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: misc | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
It would be nice if we could test coreboot images in VirtualBox, see
http://virtualbox.org/.
VirtualBox does not (yet) provide a simple mechanism to use a different
BIOS in their emulated machines (something like "-L" in qemu). Instead the
BIOS image (a custom bochs BIOS + LGPL'g VGABIOS) is converted to C code
(an array of bytes, or the like) and merged into the VirtualBox
executable.
The relevant files are
{{{
src/VBox/Devices/PC/DevPcBios.cpp
bldprogs/bin2c.c
}}}
if someone want to hack VirtualBox to easily support using coreboot images
instead of their usual BIOS.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/95>
coreboot <http://www.coreboot.org/>
I wanted to know which physical port of my multiple USB controllers have
the debug capability. There was no way to find that easily, so I created
a tool which will do most of the work for the user.
Example output:
The following PCI devices support a USB debug port (says lspci):
0000:00:1d.7
The following PCI devices support a USB debug port (says the kernel):
0000:00:1d.7
PCI device 0000:00:1d.7, USB bus 3, USB physical port 1
Currently connected high-speed devices:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
|__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Hi list(s),
Here's my second attempt at routing the previously mailed png of my schema.
It was a lot trickier to route then my previous version, but I think it
worked out!
As mentioned, S1 and S2 need to be shorted if U3 is to be omitted. RN1
should be 10k or ideally 100k, as Peter mentioned earlier.
Hopefully there's no obvious mistakes and can start working on
alternative layouts (so it is insert-able in different angles).
DRC Check fails on S1, S2 and U3. It thinks the distance is to shallow.
That said, DRC check passes when I set the copper width/distance to
7mil's instead of the current 8 mils.
I'm planning on having these PCB's manufactured by Seeed studio and
their minimal width is much smaller.
Minimum trace width: 6mil
Minimum trace/vias/pads space : 6mil
Minimum silkscreen width : 4mil
Minimum silkscreen text size : 32mil
I've used a grid size of 10mil and distances of 8 mils, as I didn't want
to rely on the minimum of seed. The silkscreen I positioned using a grid
size of 5 mil's however. Not sure what they mean with a 'minimum
silkscreen text size' however.
Anyhow, feedback greatly appreciated, so I can start working on
alternative layouts :)
Hi,
andor reported a problem where flashrom does reproducibly not work with
coreboot but does with the vendor BIOS
http://paste.flashrom.org/view.php?id=1614
Apparently it is related to fast reads and/or the frequency.
We have forced the fastReadEnable bit in the SPI_Cntrl0 from 1 to 0 and
also set NormSpeed in SPI_Cntrl1 to 16.5 Mhz (previously was 0 i.e. 66
MHz) in flashrom and the problem vanished.
Coreboot hard codes the fast read setting in
src/southbridge/amd/cimx/sb800/bootblock.c:
static void enable_spi_fast_mode(void)
{
u8 byte;
u32 dword;
device_t dev = PCI_DEV(0, 0x14, 0x03);
// set temp MMIO base
volatile u32 *spi_base = (void *)0xa0000000;
u32 save = pci_io_read_config32(dev, 0xa0);
pci_io_write_config32(dev, 0xa0, (u32) spi_base | 2);
// early enable of SPI 33 MHz fast mode read
byte = spi_base[3];
spi_base[3] = (byte & ~(3 << 14)) | (1 << 14);
spi_base[0] = spi_base[0] | (1 << 18); // fast read enable
pci_io_write_config32(dev, 0xa0, save);
}
Marc suggested that this should be configurable in the devicetree or by
a kconfig setting. Also, the statements using "byte" do not make a lot
of sense to me. Shouldn't that be a u32 instead?
The public documentation of the fastReadEnable is lacking any detail
and I don't have access to the NDAed version of the RRG. Is my theory
correct that the controller uses the 0x0B opcode with a fixed frequency
(33 MHz?) instead of 0x03 with the frequency set by NormSpeed?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
#186: 3com 3c905tx / gpxe boot problem
-----------------------------------+----------------------------------
Reporter: jeroenkrabbendam@… | Owner: stepan@…
Type: defect | Status: new
Priority: minor | Milestone:
Component: coreboot | Keywords: gpxe
Dependencies: | Patch Status: there is no patch
-----------------------------------+----------------------------------
Although (or: just because) novice in the field, I encountered some
problems with netbooting with coreboot.
Mobo's tried: Asus P2B, VTech with bios id ITE8671-2A69KV3IC-00. All
mobo's boot '''harddisk''' fine with Asus P2B / Gigabyte GA-6BX{CE}
respectively.
NIC ROM is started, and loads the kernel by tftp. This is vvvveeeerrrryyy
slow! Although loading, the kernel is never able to start itself. Same
kernel on HDU is no problem at all (GRUB2)
Note: the gpxe-image is on the nic, coreboot payload is seabios.
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/186>
coreboot <http://www.coreboot.org/>
#191: Coreboot:libpayload-size_t conflicting types compiler error
---------------------------+----------------------------------
Reporter: Pradish | Owner: uwe@…
Type: defect | Status: new
Priority: blocker | Milestone:
Component: libpayload | Keywords:
Dependencies: | Patch Status: there is no patch
---------------------------+----------------------------------
Hi
I have question related to libpayload, which I am trying to solve, but not
able to.
I have successfully build the coreboot.rom for QEMU x86.
Now when I try to build the libpayload project it throws error.
System configuration:
Virtual Box –Ubuntu 11.10 version
Building for X86 Paltform
Earlier I have run the cross toolchain using the command ‘make crossgcc’
and it was succcessfull
Error information:
/coreboot/payloads/libpayload$ make install
CC libpci/libpci.libpci.o
In File included from include/libpayload.h:54:0,
from libpci/libpci.c:30:
include/x86/arch/types.h:56:22: error: conflicting types for 'size_t'
In file included from include/libpayload.h:49:0,
from libpci/libpci.c:30:
/home/pradish/coreboot/util/crossgcc/xgcc/lib/gcc/i386-elf/4.7.2/include/stdded.h:213:23:
note: previous declaration of 'size_t' was here
make: ***[build/libpci/libpci.libpci.o] Error 1
pradish@pradish-VrtualBox:~/coreboot/paylaods/libpayload$
can you tell me, how to resolve this , I have not done any changes to the
source code. Just performed ‘make’
regards
pradish
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/191>
coreboot <http://www.coreboot.org/>
After some toing and froing with Aaron Durbin over the last 6 hours
this is where we are:
mrc.cache is now working but cold boot still takes roughly 5 seconds to
get to SeaBIOS display. Warm boot/reset is instantaneous. Aaron says the
mrc.bin blob is not happy (and we can't have an unhappy blob now, can
we).
In order to get mrc.cache working this is what's required:
1. Remove 'select CHROMEOS' from src/mainboard/samsung/lumpy/Kconfig.
2. Add this patch:
diff --git a/src/vendorcode/google/chromeos/gnvs.h
b/src/vendorcode/google/chrom
index 00fe443..5384423 100644
--- a/src/vendorcode/google/chromeos/gnvs.h
+++ b/src/vendorcode/google/chromeos/gnvs.h
@@ -61,9 +61,13 @@ typedef struct {
// dbe
} __attribute__((packed)) chromeos_acpi_t;
+#if CONFIG_CHROMEOS
extern chromeos_acpi_t *vboot_data;
void chromeos_init_vboot(chromeos_acpi_t *chromeos);
void chromeos_set_me_hash(u32*, int);
void acpi_get_vdat_info(uint64_t *vdat_addr, uint32_t *vdat_size);
+#else
+static inline void chromeos_init_vboot(chromeos_acpi_t *chromeos) {}
+#endif
#endif
3. make oldconfig
4. make clean
5. make (obviously)
Additionally, to get timing information in cbmem -c and cbmem -t the
following was necessary:
1. Add 'select LAPIC_MONOTONIC_TIMER' to
src/mainboard/samsung/lumpy/Kconfig
2. make oldconfig
3. make (again obviously)
The cbmem output is attached. Where to go from here? Many thanks to
Aaron for all his help.
Hello! Someone recently contacted me directly about my MA785GM-US2H coreboot port, and they weren't able to get the microcode to generate:
HOSTCC cbfstool/cbfstool (link)
LD cpu_microcode_blob.o
coreboot/util/crossgcc/xgcc/bin/i386-elf-ld: no input files
make: *** [build/cpu_microcode_blob.o] Error 1
I've tested the compilation process here too and I get the same problem, not sure how to fix it. It doesn't work for me no matter what board I select in Kconfig.
Please note I am not subscribed to the coreboot mailing list so if you have a response, I kindly suggest you CC the email to me directly.
Alec Ari <neotheuser(a)ymail.com>
On Wed, Jul 31, 2013 at 1:48 PM, John Lewis <jlewis(a)johnlewis.ie> wrote:
> On 31/07/2013 19:36, Aaron Durbin wrote:
>
>> On Wed, Jul 31, 2013 at 1:27 PM, John Lewis <jlewis(a)johnlewis.ie> wrote:
>>
>>> On 31/07/2013 17:51, Aaron Durbin wrote:
>>>
>>>> On Wed, Jul 31, 2013 at 11:42 AM, John Lewis <jlewis(a)johnlewis.ie
>>>> [9]> wrote:
>>>>
>>>>> On 31/07/2013 17:11, Aaron Durbin wrote:
>>>>>
>>>>>> On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <jlewis(a)johnlewis.ie
>>>>>> [8][8]> wrote:
>>>>>>
>>>>>>> On 31/07/2013 16:56, Aaron Durbin wrote:
>>>>>>>
>>>>>>>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis
>>>>>>>> <jlewis(a)johnlewis.ie [7][7][7]> wrote:
>>>>>>>>
>>>>>>>>> On 31/07/2013 16:43, Aaron Durbin wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Jul 31, 2013 at 10:34 AM, John Lewis
>>>>>>>>>> <jlewis(a)johnlewis.ie [6][6][6][6]> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 31/07/2013 16:20, Aaron Durbin wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin
>>>>>>>>>>>> <adurbin(a)chromium.org [5][5][5][5][5]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis
>>>>>>>>>>>>> <jlewis(a)johnlewis.ie [4][4][4][4][4][4]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 31/07/2013 15:33, Aaron Durbin wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis
>>>>>>>>>>>>>>> <jlewis(a)johnlewis.ie [3][3][3][3][3][3]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all, Just want to confirm where we are in
>>>>>>>>>>>>>>>> terms of things working or not. The new
>>>>>>>>>>>>>>>> system-agent binary works and recognises all
>>>>>>>>>>>>>>>> 4 GB of RAM as long as an additional pei data
>>>>>>>>>>>>>>>> field is added to Stefan's patches in
>>>>>>>>>>>>>>>> http://review.coreboot.org/#/c/3831/ [1] [1]
>>>>>>>>>>>>>>>> [1] [1] [1] [1] [1] as detailed by Kyösti in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the comments. The patches in
>>>>>>>>>>>>>>>> http://review.coreboot.org/#/c/3830/ [2] [2]
>>>>>>>>>>>>>>>> [2] [2] [2] [2] [2] don't appear to do
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> anything for mrc.cache (it's still zero size)
>>>>>>>>>>>>>>>> and this (or perhaps something else) results
>>>>>>>>>>>>>>>> in a time to SeaBIOS prompt of between 5 to 9
>>>>>>>>>>>>>>>> seconds.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you show us 'ls -l $(obj)/mrc.cache' ? I
>>>>>>>>>>>>>>> didn't see
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is your problem. I was hoping for a build.log
>>>>>>>>>>>>> that was completely clean. The build log attached
>>>>>>>>>>>>> does not show mrc.cache being created. Can you try
>>>>>>>>>>>>> the following and rebuilt? dd if=/dev/zero
>>>>>>>>>>>>> of=mrc.cache bs=16K count=1 | tr '00' '377' >
>>>>>>>>>>>>> mrc.cache
>>>>>>>>>>>>
>>>>>>>>>>>> Apologies. I am doing too many things at once.
>>>>>>>>>>>> Remove the 'of=mrc.cache' parameter to dd.
>>>>>>>>>>>
>>>>>>>>>>> The good news is that cbfstool now reports a non-zero
>>>>>>>>>>> mrc.cache, the bad news is it doesn't make any
>>>>>>>>>>> difference. cbmem -c reports Updating MRC cache data.
>>>>>>>>>>> No FMAP found at ffe70000. FMAP: area RW_MRC_CACHE not
>>>>>>>>>>> found find_current_mrc_cache_local: No valid MRC cache
>>>>>>>>>>> found. SF: Detected W25Q64 with page size 1000, total
>>>>>>>>>>> 800000 Need to erase the MRC cache region of -1 bytes
>>>>>>>>>>> at 0011037f SF: Erase offset/length not multiple of
>>>>>>>>>>> erase size Finally: write MRC cache update to flash at
>>>>>>>>>>> 0011037f ICH SPI: Data transaction error SF: Failed to
>>>>>>>>>>> send write command (1 bytes): -1 SF: Winbond Page
>>>>>>>>>>> Program failed
>>>>>>>>>>
>>>>>>>>>> CONFIG_CHROMEOS=y You have that option enabled. That's
>>>>>>>>>> why you are seeing fm> erefore, it is not using >>>> the
>>>>>>
>>>>>> mrc.cache cbfs file. There's
>>>>>>>
>>>>>>> also the fact that >>>> certain variables are not initialized
>>>>>>> properly and >>>> thinking the callee will initialize them.
>>>>>>> cache_base >>>> should be set to NULL in update_mrc_cache()
>>>>>>> before >>>> calling get_mrc_cahce_region(). You'll see more
>>>>>>>>>>>
>>>>>>>>>>> enlightening messages. That, or ensure >>>>
>>>>>>>
>>>>>>> get_mrc_cache_region NULL's out the parameter>>> don't >>>>
>>>>>>> enable >> CONFIG_CHROMEOS. > Menuconfig enables it by >> >>>
>>>>>>> default, and there is no option to > uncheck. If I set it >>>
>>>>>>> to 'n' or comment >> get: > build/generated/crt0.romstage.o: In
>>>>>>> function `main': >>> >> >
>>>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:215:
>>>>>>>>>>
>>>>>>>>>> undefined refe
>>>>>>
>>>>>> e_chromeos_gpios' > >> >
>>>>>>
>>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:362:
>>>>>>>>>
>>>>>>>>> undefined reference to `init_chromeos' > >>
>>>>>>
>>>>>> build/northbridge/intel/sandybridge/mrccache.romstage.o: In > >>
>>>>>> function `get_mrc_cache_region':
>>>>>>
>>>>>
>>>>
>>>> /home/john/coreboot/src/northbridge/intel/sandybridge/mrccache.c:71:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> undefined reference to `find_fmap_entry'
>>>>>>>>> build/northbridge/intel/sandybridge/raminit.romstage.o: In
>>>>>>>>> function `sdram_initialize':
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> /home/john/coreboot/src/northbridge/intel/sandybridge/raminit.c:240:
>>>>>>
>>>>>> undefined reference to `recovery_mode_enabled' collect2: error:
>>>>>> ld returned 1 exit status make: ***
>>>>>> [build/cbfs/fallback/romstage_null.debug] Error 1 Fantastic. In
>>>>>> src/mainboard/samsung/lumpy/Kconfig remove 'select CHROMEOS'.
>>>>>> You'll need to do a 'make oldconfig' then rebuild. Fwiw, you
>>>>>> can't set it to 'n'. It needs to be '# CONFIG_CHROMEOS is not
>>>>>> set'. But since you did set it to 'n' the dependency object files
>>>>>> weren't included in the link. Anyway, do a clean build after
>>>>>> removing 'select CHROMEOS'. hth. -Aaron Okay. We are getting a
>>>>>> bit further along now but: CC cbfs/fallback/coreboot_ram.debug
>>>>>> build/generated/coreboot_ram.o: In function `acpi_create_gnvs':
>>>>>>
>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/acpi_tables.c:102:
>>>>>>
>>>>>> undefined reference to `chromeos_init_vboot' collect2: error: ld
>>>>>> returned 1 exit status make: ***
>>>>>> [build/cbfs/fallback/coreboot_ram.debug] Error 1 Try the
>>>>>> following patch: diff --git
>>>>>> a/src/vendorcode/google/chromeos/gnvs.h
>>>>>> b/src/vendorcode/google/chrom index 00fe443..5384423 100644 ---
>>>>>> a/src/vendorcode/google/chromeos/gnvs.h +++
>>>>>> b/src/vendorcode/google/chromeos/gnvs.h @@ -61,9 +61,13 @@
>>>>>> typedef struct { // dbe } __attribute__((packed))
>>>>>> chromeos_acpi_t; +#if CONFIG_CHROMEOS extern chromeos_acpi_t
>>>>>> *vboot_data; void chromeos_init_vboot(chromeos_acpi_t *chromeos);
>>>>>> void chromeos_set_me_hash(u32*, int); void
>>>>>> acpi_get_vdat_info(uint64_t *vdat_addr, uint32_t *vdat_size);
>>>>>> +#else +static inline void chromeos_init_vboot(chromeos_acpi_t
>>>>>> *chromeos) {} +#endif #endif Or wrap the call in
>>>>>> lumpy/acpi_tables.c with '#if CONFIG_CHROMEOS/#endif'.
>>>>>
>>>>> Okay, that worked, but cold reboot takes 5 secs to SeaBIOS, warm
>>>>> reboot is instantaneous. cbmem -c output looks pretty healthy to
>>>>> me. I'll attach it anyway. What do you think?
>>>>
>>>> Was the log from a warm or cold reboot? Also, what do you mean by
>>>> cold reboot? Could you set CONFIG_LAPIC_MONOTONIC_TIMER=y? Also, if
>>>> you select CONFIG_COLLECT_TIMESTAMPS=y as well that will provide
>>>> times that can be read by the cbmem utility (-t option, I think).
>>>> With that data we can do an A/B comparison of boot times for your
>>>> warm vs cold. -Aaron
>>>
>>> Cold, I think. Cold boot - power off and switch on again after a few
>>> seconds. If I try to use both those options I get:
>>> src/lib/timestamp.c:35:31: error: unknown type name 'tsc_t' static
>>> uint64_t tsc_to_uint64(tsc_t tstamp) ^ src/lib/timestamp.c:41:1: error:
>>> expected identifier or '(' before '{' token { ^
>>> src/lib/timestamp.c:59:1: error: expected identifier or '(' before '{'
>>> token { ^ src/lib/timestamp.c:76:1: error: expected identifier or '('
>>> before '{' token { ^ make: *** [build/lib/timestamp.romstage.o] Error 1
>>
>>
>> Hrmm. I don't understand why that is failing. cpu/x86/tsc.h should be
>> included from timestamp.h. No idea why tsc_t isn't being defined.
>> Well, removing CONFIG_COLLECT_TIMESTAMPS should make your build work.
>> And we can at least see ramstage boot times.
>
>
> Attached. Cold was much slower this time.
>
> John.
Your cold logs has the following:
find_current_mrc_cache_local: No valid MRC cache found.
I take it that was after a fresh reprogram? If you do another cold
boot it should use the MRC cache.
I was going to compare the boot state times, but it seems these logs
don't have CONFIG_LAPIC_MONOTONIC_TIMER enabled?
-Aaron
