October 2013 - coreboot - mail.coreboot.org

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?
by Reiner Luett Sept. 12, 2017

Sept. 12, 2017

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

5 6

#95: Run coreboot in VirtualBox
by coreboot Dec. 10, 2014

Dec. 10, 2014

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

2 8

EHCI debug port finder
by Carl-Daniel Hailfinger May 30, 2014

May 30, 2014

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/

5 13

Dual SPI Flash adapter attempt 2.0
by Oliver Schinagl March 9, 2014

March 9, 2014

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 19

fixed AMD SPI speed settings (leading to problems on E350M1/USB3)
by Stefan Tauner Feb. 2, 2014

Feb. 2, 2014

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

2 1

#186: 3com 3c905tx / gpxe boot problem
by coreboot Jan. 11, 2014

Jan. 11, 2014

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

1 1

#191: Coreboot:libpayload-size_t conflicting types compiler error
by coreboot Nov. 5, 2013

Nov. 5, 2013

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

1 2

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)
by Scott Duplichan Nov. 5, 2013

Nov. 5, 2013

Anthony Ross wrote: ]Thanks for the heartiest reply. Well I have gone through the pros & cons of DUET & haven' t faced any hurdles thus ]successfully building it. Similarly getting to the EDK2 project I have successfully built OVMF 32 & 64 with secure boot ]configuration, integrating them with seabios as csm and initializing them in QEMU-kvm. I have also successfully built & ]booted the Coreboot Pkg IA32 encapsulating it in the coreboot.rom and booting it under QEMU-kvm except for the X64 ]architectures I faced certain toolchain errors. ] ]So if the Coreboot Pkg can boot so should DUET. I know there are both different but any how they both follow the same ]basis of the UEFI platform. I say this because the Coreboot Pkg (coreboot.rom) during its boot up shows signs of errors & ]debugging messages are worth noting but DUET (coreboot.rom) seems just absent.It also does not indicate any low ]memory problems in real mode, frankly speaking the coreboot.rom just boots as if it was built with just a seabios ]payload. Yes one thing can be noted when I had earlier booted DUET directly under QEMU it indicated something as ]'executing code out of memory' and it aborted there.Secondly taking again into concern the Coreboot Pkg it follows lzma ]compression and also DUET so any issue about that? & what about QEMU does it require any changes as for DUET It is good to hear you are you are building successfully. Here is an alternative method of booting the EDK2 Duet project. It uses the publically available AMD simnow in place of qemu. Simnow has the benefit of booting unmodified BIOS and other code. It boots the same BIOS image that is used on the real hardware. You can use simnow to ensure you have a working image. Then you can try it on real hardware. Simnow can be downloaded from here: http://developer.amd.com/tools-and-sdks/cpu-development/simnow-simulator/ I tested using the simnow model for an old AMD reference board named Solo. The limited virtual address space of the processor used in the Solo model avoids a memory overwrite bug in the Duet code. The limited DRAM of the Solo model avoids pointer truncation problems in the Duet code. Here is how I tested: 1) get EDK2 SVN version 14796 from one of the public servers. 2) build the Duet project and use the output to make a bootable hard disk image. 3) boot the hard disk image using the simnow solo model. The simulation will stop with a red screen register dump. This is due to a Duet bug where initialization of the 8254 timer while it is already running causes a spurious interrupt. Use the built-in debugger to continue out of the exception handler's hang loop. The simulation will continue and boot the UEFI shell. If you exit the shell, the UEFI menu system will run. Here it the bootable hard disk image and a Windows batch file for starting simnow. Some screen shots are also included. http://notabs.org/edk2-duet/ Once you have this much working, you could try real hardware or a different simnow model. This will expose some problems that need to be fixed in order to run on systems with larger memory and on processors with larger virtual address space. I have no experience with making SeaBIOS boot an embedded floppy image. I may be able to give this a try, but I would have to first overcome Windows build problems that have crept into both SeaBIOS and coreboot. Thanks, Scott On Wed, Oct 23, 2013 at 1:00 AM, Scott Duplichan <spambucket(a)notabs.org> wrote: Neo wrote: ]Hello ] ] There has been no response to my thread [Help required to initialize ]coreboot as Seabios (floppy mechanism for DUET) payload] since a long ]time.I have eagerly waited but no solutions have turned up. ] If Im mistaken in any way or the other please let know. ] ]Regards.... ] ]Neo. Hello, If this is really something you want I may be able to help. Be aware that Duet is not an active EDK2 project. Duet has many problems that you must solve before it is usable. The Duet concept is sound, and is a good match for coreboot. But it is not in general a usable project as it exists in the public EDK2 archive. Building Duet should be easy, relative to other EDK2 projects. Can you successfully build other EDK2 projects? From EFI's beginning in 1999 to recently, the only supported build toolset was Microsoft. Recently gnu build tool support was added. But because Duet is not an active project, it may not build easily with gnu tools. In addition, EDK2 does not properly support any Windows port of the gnu tools. So try building with Microsoft tools for a reference point. But be aware that EDK2 actually uses a hard-coded absolute path to the Microsoft tools. So unless your Microsoft build tools are installed in the same location as theirs, you will have to modify Basetools\Conf\ tools_def.template. Once Duet builds, there are some basic bugs to fix. There is a memory overlap problem for example. Duet cannot work with more than 4GB of RAM if I remember correctly. These are all easy to fix. Another problem is a limitation on the DXE image size. This limitation is due to the DOS 640 KB memory limit. The DOS 640 KB limit is relevant because the image is read from disk in 16-bit mode and low memory is the most convenient place to put it. This limitation must be removed before a full featured DXE can be used. Once all the problems are fixed, the reliance on legacy BIOS INT 13h can be removed. The image can be kept in flash and then copied to DRAM instead of reading it from a file. One of the bigger problems is that UEFI needs a large amount of NVRAM. The size is too big to fit into CMOS. That means you need to add code to write this data to flash memory. Normally a 64-KB block of the BIOS flash chip is set aside for this use. There are several more problems in addition to these. They can all be overcome, but it takes some time. The good thing about Duet is that it uses only the generic portion of UEFI, so it is easy to run on an emulator such as simnow or qemu for development and debug. Duet requires that DRAM init and any other chipset initialization be complete. Duet finds DRAM by calling E820, though passing the info directly is possible. Duet does not supply ACPI tables. It finds existing ACPI tables and uses those. Same for SMBIOS. Thanks, Scott

3 3

software hardening research project - request for advices to start
by Laurent Lesage Nov. 1, 2013

Nov. 1, 2013

Hello all, After having searched around me for some answers about BIOS and PC board "hacking", I want to ask directly to the "core" developers. In short, I would like to run a test software without OS (say, like "memtest") on a standard mainboard. This software will have to access a PCIe board, and may be some components of the mainboard. So we expect the software will not exceed a few hundred kilobytes. During this experiment, we want that a reset of the CPU does not lead to a reboot, but just restart our software immediately (only a cold start would redo all the usual "POST"), skipping all the usual hardware setups. "immediately" means in one ms or so (the less, the best). More details about what I'm working on at the end of this post. To achieve this on standard mainboards, being able to modify the BIOS seems the only way. My questions /request for comments and advices : 1.Is it feasible to modifiy the BIOS for such a reset (without POST and very quickly). 2.Is it possible to put our software on the BIOS chip, so that we do not need to access hard disk, and so that the code is protected (Read only) during the runs. 3. is it possible to flash the BIOS without locking the board, i.e., is it always possible to recover a working bios if flashing process failed, or experimental BIOS is not working as expected. In that sense, are there boards to avoid? 4.knowing we will have to access a PCIex8/16 extension board, and knowing the points 1, 2 and 3, which board would you advice to use? For example, I saw this one ( http://www.coreboot.org/ASUS_F2A85-M#Hardware_info ) for which PCIe support seems OK. Of course, the board must be easy to buy, so older ones are not a good choice if they are sold out. I also saw that some boards offers bigger space to flash BIOS. Again, this would be a good criterion for our needs, if it is possible to flash our software in it using the remaining space. What I wish is to start with a mainboard that has more than 90% of probability to meet our needs. Some more details about the project. I'm research engineer in UCLouvain (Belgium). Our topic is "software hardening for mission critical embedded software". Quickly said, we want to test our approach with COTS hardware (usually, testing is done on FPGA systems, or specific hardened hardware systems). So, we want to use a PC board to run a very specific software on it (that could be the "payload" coreboot can start). We intend to make this in two stages : -first tests on a "naked" machine i.e. without OS. Our software is the payload. That is the subject of this post. -later, run a software hardened version of Minix (I saw minix is not yet usable as such but if we come to this end, we will have some knowledge to go this way). The CPU of our "naked machine" will at the end be irradiated to inject error in it, and see if it detects errors and stays working despite transient faults. Regards Laurent board with special memory and FPGA on it

2 1

Re: [coreboot] Issues getting ASUS F2A85-M to boot
by Ward Vandewege Oct. 29, 2013

Oct. 29, 2013

On Tue, Oct 29, 2013 at 02:29:14PM -0000, Haywood-Evans Matthew wrote: > I am presently looking at trying to get Coreboot up and running on an > ASUS F2A85-M system. I am however running into some issues. > > Using a bus pirate and flashrom I first backed up the original bios, > then erased the chip and restored the bios to ensure I had the basic > read/write capability working and this all worked correctly. > > Then I proceeded to build a standard coreboot image using seabios as a > payload (using an external VGA card), leaving all the settings as > default apart from selecting the motherboard, upon writing this to the > flash and rebooting the machine I had no output from the VGA adapter and > nothing from the serial port. How did you burn the image? With the bus pirate, or from the board itself? If the latter, that would explain your problem; I've seen flashrom seemingly do the right thing when reflashing coreboot over the proprietary bios, but the board not boot. I didn't have time to investigate that at the time, sadly. Re-flashing with the bus pirate solved this for me. Note that you really still need to power off the board entirely (and let it sit a few seconds to allow the caps to drain) when switching between proprietary bios and coreboot. For me this port works out of the box with the default settings. If you like I can send you a link to a known-good image that we use here, so that you can verify your hardware is ok. Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://status.fsf.org/ward http://fsf.org/blogs/RSS | http://identi.ca/cure Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859

1 0