coreboot November 2015

coreboot@coreboot.org

38 participants
97 discussions

CBMEM Console corruption with fsp_baytrail in coreboot 4.2
by Ben Gardner 19 Nov '15

19 Nov '15

Hi, I've narrowed down where the CBMEM console is getting corrupted and found a work around that gets it working again. It is getting corrupted in the FSP Early Init function. So in the Intel blob, not coreboot. I added logs to cbmemc_init() and cbmrmc_reinit() that show the console pointer, size, cursor and the first 64 bytes of the console (including size and console). Right before the call to FspInitApi() in fsp_early_init(): fsp_early_init: cbm_cons_p: fef00000 size=3064 cur=2606 fef00000: f8 0b 00 00 7b 0a 00 00 63 62 6d 65 6d 63 5f 69 ........cbmemc_i fef00010: 6e 69 74 3a 20 63 62 6d 5f 63 6f 6e 73 5f 70 3a nit: cbm_cons_p: fef00020: 20 66 65 66 30 30 30 30 30 20 73 69 7a 65 3d 33 fef00000 size=3 fef00030: 30 36 34 20 63 75 72 3d 30 0a 66 65 66 30 30 30 064 cur=0.fef000 And this is at the top of romstage_main_continue(): romstage_main_continue: cbm_cons_p: 00000b96 size=2052398204 cur=1024945500 00000b96: 7c 1c 55 7a bd 6d 17 3d 17 a9 76 69 ee 07 d1 b8 |.Uz.m.=..vi.... 00000ba6: fa 6b 75 85 ee 7a dd 8f e9 48 59 93 b4 f8 0a ce .ku..z...HY..... 00000bb6: 1c dc fe a4 09 d6 ba 1d 88 8f 23 e4 40 cc 88 cd ..........#.@... 00000bc6: 90 91 53 e4 71 6d 90 1d bd e9 fa 13 a8 16 fd b5 ..S.qm.......... So, the FSP is trashing the CAR variables. I looked at the changes to src/arch/x86/car.ld and see that the CONSOLE line was moved before _car_data_start. That move appears to have been in commit dd6fa93d by Aaron Durbin. http://review.coreboot.org/#/c/11740/3/src/arch/x86/car.ld When I moved that CONSOLE line back to after _car_data_end, the console works again. That also fixes the timestamp table infinite loop issue. So, I have a work-around. However, I suspect that the root issue of the FSP trashing CAR variables persists. My initial email about the timestamp issue is here: http://www.coreboot.org/pipermail/coreboot/2015-November/080719.html I'm not sure what to do about this. The above change seems reasonable and needed for verstage support, so sending my 'fix' upstream probably isn't viable. Suggestions? Thanks, Ben

3 2

Payload that can do mmio32/pciserial UART on x86
by Alex G. 19 Nov '15

19 Nov '15

Is there such a payload? Seabios is stuck with IO UARTs. Not sure if grub can handle it (and if so, how). Depthcharge is out of the question because it is unbelievably difficult to build outside chromium os's uber-cumbersome build system. So, is there something? Alex

3 3

ASUS KFSN4-DRE (K8) Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 18 Nov '15

18 Nov '15

The ASUS KFSN4-DRE (K8) fails verification as of commit 1455437c9e010bcc617c5927e18cf1cb3b02c82f The following tests failed: BOOT_FAILURE Commits since last successful test: See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Infinite loop with fsp_baytrail and COLLECT_TIMESTAMPS in coreboot 4.2
by Ben Gardner 18 Nov '15

18 Nov '15

Hi all, Has anyone else tried coreboot 4.2 on fsp_baytrail with COLLECT_TIMESTAMPS enabled? I'm seeing the console flooded with an infinite loop of "ERROR: Timestamp table full". The last few post codes are: 4a 4b 4c 4d. That puts it in fsp_baytrail / romstage.c in romstage_main_continue(): ... /* if S3 resume skip ram check */ if (prev_sleep_state != 3) { quick_ram_check(); post_code(0x4d); } cbmem_was_initted = !cbmem_recovery(prev_sleep_state == 3); /* Save the HOB pointer in CBMEM to be used in ramstage*/ cbmem_hob_ptr = cbmem_add (CBMEM_ID_HOB_POINTER, sizeof(*hob_list_ptr)); *(u32*)cbmem_hob_ptr = (u32)hob_list_ptr; post_code(0x4e); ... I had console logging set at NOTICE, so I missed some possibly important logs. Based on a look through the code, I'm guessing the call tree is: romstage_main_continue() cbmem_recovery() cbmem_initialize_empty() cbmem_initialize_empty_id_size() cbmem_run_init_hooks() timestamp_sync_cache_to_cbmem() timestamp_add_table_entry() Side note: it takes 15 minutes to load the BIOS using an external programmer, so I didn't experiment too much. (Vs. ~30-60 seconds if programmed using flashrom on the target.) I just turned off timestamps and reloaded and it boots fine. Any ideas? Prior to rebasing on 4.2, I didn't have any issues with timestamps. I was using 4.1 + a few patches. Thanks, Ben

1 2

questions about veyron boards and the rk3288
by Anthony Martin 17 Nov '15

17 Nov '15

1. Is veyron_mickey the ASUS Chromebit CS10? 2. Are any of the veyron_(danger|rialto|emile) products released yet? 3. Also, is the RK3288 TRM available without an NDA? Cheers, Anthony

2 1

Understanding BIOS I/O Adresses
by panic 17 Nov '15

17 Nov '15

Hi, out of curiosity, I'd like to reverse engineer - or at least try to understand a bit more of - the (old/classic/non-EFI) proprietary BIOS of my HP nc6320 laptop (BIOS dated from 2008). I'm fairly new to BIOS code and so far it's been a series of great discoveries and interesting reading for me :-) I unsoldered the 8Mbit SPI flash from a damaged/broken laptop of the same type and dumped its contents, and now analyse it with radare2. At a very early stage (see below) I have some difficulties to understand what is done: the code accesses IO locations (via in/out instructions) that belong to the DMA controller but are marked "Reserved" in the ICH7 documentation [0, page 385]. Is there a way to find out what these addresses are used for? http://www.coreboot.org/HP_COMPAQ_NC6320 - Processor: Intel Core 2 Duo T7200 - Northbridge: 945GM - Southbridge: Intel 82801GBM (ICH7-M) Concerning "reserved" addresses, [0, page 255] says: "DMI (Direct Media Interface) cycles that go to target ranges that are marked "Reserved" will not be decoded by the ICH7, and will be passed to PCI" In particular I'm interested in 0x80, 0x84/0x85, 0x8c/0x8d. Since dx contains CPU type/family information, does the code tell other components some CPU specifics? f000:fff0 e9f591 jmp loc.000f91e8 | v f000:91e8 fa cli f000:91e9 e784 out 0x84, ax f000:91eb 8bc2 mov ax, dx f000:91ed e78c out 0x8c, ax f000:91ef b0b0 mov al, 0xb0 f000:91f1 e680 out 0x80, al f000:91f3 ba4e05 mov dx, 0x54e f000:91f6 ee out dx, al f000:91f7 e58c in ax, 0x8c f000:91f9 8bd0 mov dx, ax f000:91fb e584 in ax, 0x84 f000:91fd bd0392 mov bp, 0x9203 f000:9200 e9b001 jmp loc.000f93b3 ;[1] | +-> ; this function basically follows f000:93b3 662e0f011ed. o32 lidt [cs:0x91dc] f000:93ba 662e0f0116d. o32 lgdt [cs:0x89d0] ; set PE bit (Protection Enable) in cr0: switch to protected mode ... ; init the segment registers ; clear PE bit in cr0: switch to real-address mode ; clear PG bit in cr0: disable paging ... ; init the segment registers to another value f000:93f6 ffe5 jmp bp | <-+ f000:9203 bd0992 mov bp, 0x9209 f000:9206 e92bf4 jmp fcn.000f8634 ;[2] | +-> ; some other stuff happening ; return via jmp bp | <-+ f000:9209 e784 out 0x84, ax f000:920b 8bc2 mov ax, dx f000:920d e78c out 0x8c, ax f000:920f b0b1 mov al, 0xb1 f000:9211 e680 out 0x80, al f000:9213 ba4e05 mov dx, 0x54e f000:9216 ee out dx, al f000:9217 e58c in ax, 0x8c f000:9219 8bd0 mov dx, ax f000:921b e584 in ax, 0x84 ... Thanks for any assistance and pointers, -- panic [0] http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datashe…

3 3

Re: [coreboot] G505s status (and test report)
by Felix Held 17 Nov '15

17 Nov '15

Hi Florentin! > As for adding support for Bolton and refactoring and unifying the FCH code, I would like to pick up the task, because I want to invest myself in coreboot dev again and I hope that I will have some time to spend in the near future... Great! IIRC someone in the IRC channel was also interested in the Bolton FCH; maybe you could work on that together. I don't remember the nickname though. > But I need to understand a little bit more the current architecture of coreboot and also the impact of recent developpements like the (proposed) switch from AGESA to native init.. > But just to have an idea of the complexity of this task (refactoring amd fch code) can you give me some details of what needs to be done? The FCH code of AGESA fam12, fam15tn and fam16kb isn't in a separate directory, but inside AGESA vendorcode. Which FCH code gets build, doesn't depend not on the southbridge Kconfig setting. Both fam12 and fam15tn trees include support for Hudson; the version in fam15tn is newer and likely has some bugfixes. The FCH code in fam16kb is different (Yangtze), but not too different. I'd try to move the FCH support out of the different vendorcode/agesa subtrees into one tree structure in vendorcode/ages. Maybe see http://review.coreboot.org/#/c/7782/ for something to begin your work. When moving the code out of the AGESA subtrees you should adapt the Kconfig stuff, so that the selection of the FCH code depends on the selected southbridge. That might involve some patching to the subtrees where you factor out the FCH support. When you have factored out the FCH vendorcode and somehow merged it into one directory structure where only the stuff relevant for one platform gets built, it should be relatively easy to extend the support for Bolton FCH. On the AGESA stuff: It seems that the internal tree has support for all different families in one tree and only the source code which is relevant for one family gets built for that family. Before the code drop for each family everything unneeded for that family was removed and the remaining stuff of that tree was released for that family. I can really recommend the 3 way folder compare mode of meld for the task of merging the 3 different FCH support code subtrees. fam12 and fam15tn have code for the same chips, but slightly different code; i'd use the newer version (fam15tn), since it likely contains some bugfixes. To get the XHCI support on Bolton working, you'd at least have to patch Hudson2XhciResetService.c; in that file the code matches onto the PCI ID of the XHCI controller, which changed between Hudson and Bolton. You likely need to patch some other stuff as well to get the XHCI controller working. When you have moved the FCH code out of the AGESA subtrees, it would be really great if you'd write native initialization for the FCH, which can be uses from both AGESA-based (maybe some glue code to AGESA is still needed for that) and native init based boards, but thats likely a non-trivial task. I hope that this helps you a bit; that was more or less everything i remember from working on that. The current state of the code isn't pretty, but you'll see that quite quickly... Also have a look at my (unfinished) Bolton support without working XHCI. Maybe it just needs the small patch that it also matches on the PCI ID of the XHCI controller in Bolton, but well, that would just be a hack. Regards Felix

1 0

Some feedback regarding the coreboot hackaton poll
by echelon＠free.fr 17 Nov '15

17 Nov '15

Hello all, First of all I want to reassure everbody who participated to the poll for the hackaton in Paris, that it is NOT canceled (in the light of the recent events..) and that I am more deternined than ever to make it happen!.. On the other hand, at the time when I launched this poll (maybe a bit prematurelly), I was missing some important information regarding other initiatives about potential coreboot meetings in 2016, some of them related to important events which could have a big impact on the visibility of our project coreboot in the open source ecosystem. But I will let the persons which are driving these initiatives to make an anouncement themselves. Regarding the hackaton in Paris, and taking into account these informations (not yet officially announced), I cannot yet anounce a firm date for the Paris venue, because we need to accomodate the Paris meeting with other important coreboot events which will take place in 2016. Stay tunned.. Best regards, Florentin Demetrescu

1 0

Re: [coreboot] Long boot delay with a large CBFS
by Stefan Reinauer 16 Nov '15

16 Nov '15

* Ben Gardner <gardner.ben(a)gmail.com> [151116 19:32]: > [The previous email got chopped. This is a re-send.] > > Hi all, > > I have a 16 MB BIOS flash on a fsp_baytrail based design. > > I tried expanding the CBFS to fill the whole space, but found that to > cause a 10-15 sec boot delay. Sounds like your CBFS file got corrupted. Anything you can share about your build (e.g. log, source code) will raise the chance of getting this fixed. Are you running without ME firmware? What do your sections look like in the firmware descriptor? Stefan

2 1

Re: [coreboot] Long boot delay with a large CBFS
by Werner Zeh 16 Nov '15

16 Nov '15

Hi Ben. I currently use a Bay Trail design with 16 MB SPI flash of which 14 MB are used for CBFS. I Never have seen such effects on my system. Do you use the latest coreboot tree (master)? Werner Am 16.11.2015 um 19:32 schrieb Ben Gardner: > [The previous email got chopped. This is a re-send.] > > Hi all, > > I have a 16 MB BIOS flash on a fsp_baytrail based design. > > I tried expanding the CBFS to fill the whole space, but found that to > cause a 10-15 sec boot delay. > > The offending code appears to be in cbfs_locate() in lib/cbfs.c: > if (memcmp(file.magic, CBFS_FILE_MAGIC, sizeof(file.magic))) { > offset++; > offset = ALIGN_UP(offset, CBFS_ALIGNMENT); > continue; > } > > In SeaBIOS, the equivalent code does a break instead of a continue. > > I'n not terribly familiar with the design goals of the CBFS. > > What is the purpose behind continuing if a bad entry is encountered? > It appears that a 'bad' entry only occurs at the end of the CBFS. > > Thanks, > Ben >

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2015