coreboot August 2014

coreboot@coreboot.org

43 participants
102 discussions

Re: [coreboot] good news on video init
by Stefan Reinauer 12 Aug '14

12 Aug '14

* ron minnich <rminnich(a)gmail.com> [140809 05:24]: > Some of furquan's very fine work from -- yegads! -- a year ago is just > now coming upstream. Take a look. Ron! If you have a link for us, that would be great! I want to endorse Furquan's great work, however. Not only did it open up new ways of making sure we get rid of yet another blob in our systems, but it also opens up coreboot on a variety of systems in the future while silicon vendors slowly but steadily migrate away from x86 VGA option ROMs and towards UEFI option roms and (sic!) GOP drivers. Also, at this time, thank you very much to every one in the community who put endless hours of effort into porting native graphics init to their mainboard / system. This is really where we have to put a lot of effort in, in the near future to keep coreboot free. Stefan

1 0

Re: [coreboot] board_status.sh output from PC Engines ALIX 2c3
by Patrick Georgi 12 Aug '14

12 Aug '14

Am 12.08.2014 um 03:27 schrieb Sevan / Venture37: > It seems that the status-to-wiki.sh script is broken, apart from being > non-portable, it appears that the board model/manufacturer is being > used as the date on Linux when run in a bash shell The status-to-wiki script is run hourly on the server, parsing the data submitted to the board-status repository (eg through board_status.sh -u) Patrick

1 0

board_status.sh output from PC Engines ALIX 2c3
by Sevan / Venture37 12 Aug '14

12 Aug '14

Hi, It seems that the status-to-wiki.sh script is broken, apart from being non-portable, it appears that the board model/manufacturer is being used as the date on Linux when run in a bash shell date: invalid date `yangtze' date: invalid date `yabel' date: invalid date `xe7501devkit' date: invalid date `xcompile' date: invalid date `x86emu' date: invalid date `x86' date: invalid date `x86' date: invalid date `x86' date: invalid date `x7db8' date: invalid date `x6dhr_ig2' date: invalid date `x6dhr_ig' date: invalid date `x6dhe_g2' date: invalid date `x6dhe_g' date: invalid date `x6dai_g' date: invalid date `x60' date: invalid date `wtm2' date: invalid date `wpcm450' date: invalid date `winnetp680' date: invalid date `winnet100' grep: src/mainboard/lenovo/x230/revision.txt: No such file or directory date: invalid date `w83977tf' date: invalid date `w83977f' date: invalid date `w83795' date: invalid date `w83793' date: invalid date `w83697hf' date: invalid date `w83627uhg' date: invalid date `w83627thg' date: invalid date `w83627hf' date: invalid date `w83627ehg' Hence I couldn't follow through with making a submission so instead, I've uploaded the contents of the text files created by board_status.sh to pastebin if anyone is interested. http://pastebin.com/r4H5ceN7 Regards Sevan / Venture37

1 0

Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
by ron minnich 12 Aug '14

12 Aug '14

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

1 0

Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
by Piotr Król 11 Aug '14

11 Aug '14

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/hw/arm/vexpress.c index a88732c..67f266a 100644 --- a/hw/arm/vexpress.c +++ b/hw/arm/vexpress.c @@ -84,7 +84,7 @@ enum { }; static hwaddr motherboard_legacy_map[] = { - [VE_NORFLASHALIAS] = 0, + [VE_NORFLASHALIAS] = -1, /* CS7: 0x10000000 .. 0x10020000 */ [VE_SYSREGS] = 0x10000000, [VE_SP810] = 0x10001000, Unfortunately this won't fix '-bios' option only '-kernel'. So it looks like the difference is that with VE_NORFLASHALIAS=0 we have vexpress.flash0 as alias to 0x0-0x3ffffff, but without it this range is mapped to vexpress.highmem. '-kernel' parameter put coreboot.rom into highmem. Does anyone know what is the correct memory map for qemu-armv7 and where coreboot.rom should be placed ? I will try to debug '-bios' option as Peter points that address in lowmem looks better for him. I will see if this option worked in the past. Thanks, Piotr > > ron > > On Mon, Aug 11, 2014 at 2:09 AM, Piotr Król <pietrushnic(a)gmail.com> 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 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 '-s -S'. Whole qemu command: > >> > > >> > qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom > >> > >> Is -kernel really correct for coreboot.rom ? > > > > This is option from commit message when qemu-armv7 was introduced > > (7635a60). I also tried '-bios' but it gives same result but with > > different address (not 0x6001024f but 0x0000024f). > > > > What I see now is that I made mistake during bisect and it was not the > > correct commit that I point to. The correct change causing problem is > > exactly one before: > > > > http://git.qemu.org/?p=qemu.git;a=commit;h=6ec1588e09770ac7e9c60194faff6101… > > > > Sorry for confusion - first time bisect user. This commit is directly > > related to vexpress-a9 board. > > > > Piotr > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

2 1

global changes and checking programs
by ron minnich 11 Aug '14

11 Aug '14

There's lots of really nice work going on with clang and other tools. I just want to put out a word of caution, based on what I'm seeing. A number of these tests are going in with global changes, no testing, and in some examples, no clear improvement or bug fix, e.g. "remove all blank lines at the end of a file", which can cause issues for others to pick over later. We all make mistakes. It is a given that some of these changes will have errors. In many cases there is no testing because most people only have one board, and they are changing many boards. Worse, they are changing them at the behest of warnings from a new toolchain or checker. I can't tell you how many issues we've had with toolchain over the years; they've been frequent. Changes driven by toolchain warnings worry me. I was just involved in a port last week and one of the coreboot utilities was always exiting via core dump. We don't know why yet as it does not fail under gdb. But it's disconcerting to find a formerly-working tool suddenly breaking. So here are the things that can happen. 1. code change for N boards, test none, break 1 or more or N 2. code change for N boards, test one, break 2 or more or N 3. cosmetic change for N boards, create a bug due to a later merge issue (latest greatest example: changing 'haven't' to 'have not' caused a bad merge) 4. code change for a tool, fixes no real problem, creates a future problem due to incorrect coding -- but the audit tool reports no errors (this means that in part the audit tool has errors) e.g. main(){ char *s = malloc(x); lots of code some of which uses s point A: lots of code NONE of which uses s } cppcheck reports a non-freed variable. Somebody puts a free(s) at point A: But they don't set s to NULL -- a common mistake. Result: s is pointing to freed memory, which is unquestionably far worse than the leak cppcheck claims is there. cppcheck and poor practice induced a bug. 5. Add broken cpp guards which cause more troubles than they might solve due to "best practices" -- which IMHO they are not. These are five types of errors I've seen in the last week, there are certainly more. Just please be very careful. Code check tools are no replacement for careful code changing. We've had lots of situations where people broke boards or tools by "improving" code. The time delay from a coreboot change to someone testing a board can be long. It's no fun to spend time debugging an ugly problem arising from a misguided attempt to clean up code. To give you some idea of what a reasonable test infrastructure looks like, see this: http://build.chromium.org/p/chromiumos/waterfall?reload=60 For every coreboot patch, these tests run on real hardware. Every one. It's why I'm so willing to trust the chromeos upstreaming: if I'm familiar with the CL, and it looks the same as it did when I wrote or reviewed it, and jenkins is happy, it's been through a good testing cycle. It's very hard to do that for all coreboot boards, however. So, please, take care. ron

1 0

coreboot bof at ELC Europe oct. 13-15
by ron minnich 11 Aug '14

11 Aug '14

got accepted. See you there. ron

1 0

Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
by Piotr Król 11 Aug '14

11 Aug '14

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 do my best. Problem occurs at very early phase. There is no coreboot gdb support so I used qemu '-s -S'. Whole qemu command: qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom -s -S Exactly at address 0x6001024f qemu tries to execute: 0x60010249: adds r3, #1 0x6001024b: cmp r3, #7 0x6001024d: bne.n 0x6001019c => 0x6001024f: ldmia.w sp!, {r2, r3, r4, r5, r6, r7, r9, r10, r11, pc} 0x60010253: movs r3, #0 0x60010255: mcr 15, 0, r3, cr8, cr7, {0} 0x60010259: mcr 15, 0, r3, cr8, cr6, {0} 0x6001025d: mcr 15, 0, r3, cr8, cr5, {0} I can't find this instruction in coreboot code. Registers before executing ldmia: R0: 0x00000002 R1: 0x00000000 R2: 0xFFFFFFFE R3: 0x00000007 R4: 0x00000000 R5: 0x00000000 R6: 0x09000003 R7: 0x00000004 R8: 0x00000000 R9: 0x00000000 R10: 0x00000000 R11: 0x00000000 R12: 0x00000000 SP: 0x0007FEA8 LR: 0x6001032F PC: 0x6001024E And after: R0: 0x00000002 R1: 0x00000000 R2: 0x00000000 R3: 0x00000000 R4: 0x00000000 R5: 0x00000000 R6: 0x00000000 R7: 0x00000000 R8: 0x00000000 R9: 0x00000000 R10: 0x00000000 R11: 0x00000000 R12: 0x00000000 SP: 0x0007FED0 LR: 0x6001032F PC: 0x00000000 PC goes to 0 and we jumping to code where is 'andeq r0, r0, r0'. Qemu execute the same instruction till PC reach 0x4000000, then ends execution with: > > qemu: fatal: Trying to execute code outside RAM or ROM at 0x04000000 Hope this is enough information. Thanks, Piotr

3 3

Re: [coreboot] why is firmware 32 bit as opposed to 64 bit
by ron minnich 11 Aug '14

11 Aug '14

I understand the arguments. It's worth remembering that coreboot has to date run on 5 different architectures. 4 of those used paging. The x86 has always been the outlier. Lack of paging has costs not discussed much. Rmodules would be a lot simpler if we had paging. We could make the code space readonly, which we should be doing anyway. We would have less fighting with the granularity and alignment restrictions of MTRRs. We could catch NULL pointers in hardware. These are clear benefits. And they all apply to the ramstage as well as other stages. As to 64 bit ramstage, I see lots of benefits for my use cases, but I may be the only one. In any event, this is all stuff that can be measured, and I propose to implement and measure it. Then we can see. I'm not convinced that a few percent either way on code size is a showstopper. ron

1 0

why is firmware 32 bit as opposed to 64 bit
by John de la Garza 11 Aug '14

11 Aug '14

I understand that the calling functions in 32 bit C uses the stack and this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use registers to pass arguments to functions? If this is the case why not run in 64 bit mode? Also, even if cache as RAM is used and a stack is available, why not just build a 64 bit binary? What are the advantages to using a 32 bit binary?

6 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2014