#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 :)
Hallo,
Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too.
I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available.
I've put the log files here: http://macbook.donderklumpen.de/coreboot/
Any comment about what you think about this and how I should proceed is very much welcome!
thanks
Mono
Hi everyone,
Quick question: what is the status of coreboot + some payload being used with
the Samsung XE303CE ARM Chromebook (snow)?
The page at [http://www.coreboot.org/Chromebooks] says 'Snow has das U-Boot
nativly installed, but a coreboot port is available.', and the page at
[http://www.coreboot.org/Supported_Motherboards] has 'Google Snow - Samsung
Exynos 5250' under the 'Motherboards supported in coreboot', but I haven't been
able to find any blog / example of anyone actually flashing coreboot + some
payload and booting their Chromebook like a regular computer.
It seems like there is a port available but no one has tried it from start to
finish on the ARM Chromebook (where my definition of finish in this context is
'booting with coreboot to stock Debian Linux', for example). I'm very keen on
doing this myself, and was hoping to find some example that I could read through
or even follow. This whole process of flashing a new BIOS is very new to me, and
I'm wary because of the potential to easily brick my device (however I'm not
scared off by reflashing or external chip programming if it comes to it, I'd
just like to avoid it).
Thanks for your time,
James
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
On 31.01.2014 20:30, ron minnich wrote:
> If you want a laptop to tear into and learn from, the old samsung x86
> chromebook is hard to beat. ram and disk are standard and upgradable,
> you can put a clip on the flash part, ...
Lenovo X201 and X230 both have those characteristics as well. Unlike
chromebooks it doesn't come with a nice firmware preinstalled though.
But I have to admit that compared to other vendors (especially the one
called "To be filled by O.E.M."), lenovo's BIOS and EFI are good.
> it's just a very hackable
> machine. I still have one and really like it.
>
> More recent ones to mess around with include the acer c720.
>
> The difficulty of dealing with chipsets is what keeps me pushing on
> chromebooks. It's a real time saver. I'd still like to find an AMD
> solution however.
>
I'm thinking of lenovo x140e. Not available in Europe though.
> ron
>
On 29/01/14 22:03, Aaron Durbin wrote:
>>
>> This is where we reach the crux of the matter - In the stock/shellball
>> firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in
>> upstream coreboot or CrOS coreboot can decipher. Looking at the file in
>> hexedit it appears to be almost identical to a CBFS that is recognised, but
>> that's it. I have managed to extract the SVGA binary from the CBFS in the
>> RW_LEGACY slot, and I've made an educated guess as to where the system-agent
>> begins and ends in the unrecognised CBFS (section beginning "LARCHIVE
>> mrc.bin" or similar with the binary itself following, surrounded by FF's)
>> copying and pasting it to a file. I would like to know if I am correct in my
>> assumptions about extracting that file manually and what size it should be,
>> in bytes?
>>
>
> That's interesting. It is just a regular 'ol cbfs. The images that
> shipped with your device is an 8MiB SPI. First 2MiB Duncan covered.
> The next 5 have nothing to do w/ coreboot proper -- all the extra
> vboot firmware bits. The last 1MiB is the cbfs.
>
Okay, well I extracted the attached file using:
eval `./fmap_decode bios.bin | grep BOOT_STUB`
dd if=c720.rom ibs=$((area_offset)) skip=1 | dd bs=$((area_size))
iflag=fullblock of=c720-coreboot.bin
and:
../coreboot/build/cbfstool c720-coreboot.bin print
produces:
c720-coreboot.bin:
1024 kB, bootblocksize 3144, romsize 8388608, offset 0x700000
alignment: 64 bytes
Name Offset Type Size
zippo.
On 31.01.2014 17:08, Roberto A. Foglietta wrote:
>
>
>
> 2014-01-31 Peter Stuge <peter(a)stuge.se <mailto:peter@stuge.se>>:
>
> Roberto A. Foglietta wrote:
> > I check the list of supported motherboards and laptops but I did
> not found
> > in them the Lenovo Thinkpad T61
>
> That means that it is not supported.
>
>
> Thanks Peter for the fast answer.
>
>
>
> > I would like to understand the magnitude of probability to brick
> > the laptop before.
>
> The probability is 1.0.
>
>
> I am interested in the probability after some development / adaption,
> not as-is.
>
> How much developing effort do you think the support of T61 would require?
>
Northbridge (i965) is unsupported. It's almost impossible to write
raminit without having a lot of low-level experience and even then it
takes couple of months of quite intensive work.
You may get lucky and i945 raminit may work with only minor adaptations but:
1) I wouldn't count on it
2) And even then find out what exactly needs adaptation is no easy task.
I have a laptop with i965 as well, in storage but I have to tell it's
simply not worth the effort. You'd be better off cuying some recent
supported laptop (see supported mobos pages, especially chromebooks and
Lenovos) or some almost supported laptop and adapt to it. But:
a) Problems may pop up in unexpected places.
b) While guys in #coreboot are extremely helpful you end up being on
your own in 95% of problems (unless someone has a similar chipset and
works on it, currently nobody AFAIK).
c) Easiest (but not easy) to adapt would be (from easiest to difficult,
no guarantee, problems may pop up in unexpected places):
- T410. All components are already in the tree. The problem with this
laptop is that it has TSOP chip, for which clip is very expensive, so
you probably would have to solder to the chip with all the risks it
entails. Actually for most people it means to ask someone to solder for you
- Nehalem-based laptops. Main problem is likely EC
- AMD-based laptops. Main problem is likely EC.
- Lenovo *30 laptops (ivybridge). Dual graphics can be a headache but
it's feasible. If chip is TSOP, see T410 comment.
- Other ivy or sandy laptops. Depends on how much MRC code likes or
dislikes your laptop.
I repeat again that even the easiest ones are hard if you have no
low-level experience and even if you do can become hard in case of
unexpected problem.
On the other hand if you're curious about it , do it! It's a fantastic
learning experience.
> To answer to this second question I suppose you need logs, do not you?
>
lspci -vvnn is available for most laptops with quick google. It (+some
experience with individual manufacturers about EC interface) allows to
estimate hardness.
> Cheers,
> R.
>
>
>