coreboot January 2014

coreboot@coreboot.org

54 participants
116 discussions

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

4 years, 9 months

#95: Run coreboot in VirtualBox

by coreboot

#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/>

7 years, 6 months

EHCI debug port finder

by Carl-Daniel Hailfinger

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/

8 years, 1 month

Dual SPI Flash adapter attempt 2.0

by Oliver Schinagl

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 :)

8 years, 3 months

coreboot port for macbook2,1

by Mono

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

8 years, 4 months

Question about status of coreboot on the Samsung XE303CE ARM Chromebook (snow)

by James MacMahon

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

8 years, 4 months

fixed AMD SPI speed settings (leading to problems on E350M1/USB3)

by Stefan Tauner

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

8 years, 5 months

Re: [coreboot] Lenovo Thinkpad T61

by Vladimir 'φ-coder/phcoder' Serbinenko

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 >

8 years, 5 months

Re: [coreboot] C720 swapparoo

by John Lewis

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.

8 years, 5 months

Re: [coreboot] Lenovo Thinkpad T61

by Vladimir 'φ-coder/phcoder' Serbinenko

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. > > >

8 years, 5 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2014