Re: [coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2017 11:40 AM, Raptor Engineering Automated Coreboot Test Stand
wrote:
> The ASUS KGPE-D16 fails verification for branch master as of commit 
> 0e3c59e258e0eb1cabe2ab15286f73efbf36294d
> 
> The following tests failed:
> BOOT_FAILURE

Regarding this series of false negatives, they may be related to an
increase in overall boot time rather than an issue in coreboot itself.
I have increased the boot timeout on this board; hopefully this will
prevent future false negatives.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYnhAcAAoJEK+E3vEXDOFbImkH/0ZJbDykwR162+j5HlUYw4sP
2usNRIlv1ujITv05c+bymMT4zYHtEDi8eDb3U6ArckO+rY6kkKXq9nqI3iynLSed
xJZ5bJe7XY/65UBOPyewqgRh5AcVYH1eLcx0CFmIdFWq83FQZFTUckszfQsroKLO
G8/bItJhv53eUCtigMEwd1oF8TvIWeMWHGIk094qZmfP+kOA1sVazXLQ2/pcqATW
24hGQF4TVJaEdfVUnopPUSF6WG3IttI1yNW/ANNdJMXO5WTTfU4nAZCrr3c0Am1o
s6DkuVNzD9SCiRqoGmTkbx/mqz4BFi2XFFtlPEikO3QLjBlA1cTovGy+T5raalU=
=d0xL
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Raptor Engineering Automated Coreboot Test Stand]

The ASUS KGPE-D16 fails verification for branch master as of commit 
0e3c59e258e0eb1cabe2ab15286f73efbf36294d

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
0e3c59e ddr3 spd: move accessor code into lib/spd_bin.c
2e08b59 ddr3 spd: Rename read_spd_from_cbfs() to read_ddr3_spd_from_cbfs()
ded1e05 util/romcc: Don't reference a variable after checking it for NULL
44a46a1 device/dram: use global DIMM_SPD_SIZE Kconfig variable
d09dc6b cbmem_console: Remove "buffer_" prefix from all structure fields
24de3a3 vendorcode/intel/skykabylake: Update FSP UPD header files
6ff7e8f vendorcode/intel/skykabylake: Update CpuConfigFspData.h file
0254c2d southbridge/intel/common/firmware: allow locking ME without HAVE_ME_BIN
7d14af8 soc/intel/apollolake: dump CSE status

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS 
KGPE-D16 test stand
Want to test on your own equipment?  Check out 
https://www.raptorengineering.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit 
https://www.raptorengineering.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1486748356-3-automaster.log.bz2
Description: application/bzip2
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin]

Hi,

Please find the latest report on new defect(s) introduced to coreboot found 
with Coverity Scan.

34 new defect(s) introduced to coreboot found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 20 of 34 defect(s)


** CID 1370577:  Resource leaks  (RESOURCE_LEAK)
/util/cbfstool/cbfscomptool.c: 83 in benchmark()



*** CID 1370577:  Resource leaks  (RESOURCE_LEAK)
/util/cbfstool/cbfscomptool.c: 83 in benchmark()
77 
78  clock_gettime(CLOCK_MONOTONIC, _e);
79  printf("compressing %d bytes to %d took %ld seconds\n",
80  bufsize, outsize,
81  t_e.tv_sec - t_s.tv_sec);
82  }
>>> CID 1370577:  Resource leaks  (RESOURCE_LEAK)
>>> Variable "compressed_data" going out of scope leaks the storage it 
>>> points to.
83  return 0;
84 }
85 
86 int compress(char *infile, char *outfile, char *algoname)
87 {
88  int err = 1;

** CID 1370575:  Resource leaks  (RESOURCE_LEAK)
/util/cbfstool/cbfscomptool.c: 83 in benchmark()



*** CID 1370575:  Resource leaks  (RESOURCE_LEAK)
/util/cbfstool/cbfscomptool.c: 83 in benchmark()
77 
78  clock_gettime(CLOCK_MONOTONIC, _e);
79  printf("compressing %d bytes to %d took %ld seconds\n",
80  bufsize, outsize,
81  t_e.tv_sec - t_s.tv_sec);
82  }
>>> CID 1370575:  Resource leaks  (RESOURCE_LEAK)
>>> Variable "data" going out of scope leaks the storage it points to.
83  return 0;
84 }
85 
86 int compress(char *infile, char *outfile, char *algoname)
87 {
88  int err = 1;

** CID 1361275:(TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 838 in parse_subpart_dir()



*** CID 1361275:(TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 831 in parse_subpart_dir()
825 memcpy(hdr.name, data + offset, sizeof(hdr.name));
826 offset += sizeof(hdr.name);
827 
828 validate_subpart_dir_without_checksum((struct subpart_dir 
*), name);
829 
830 assert(size > subpart_dir_size());
>>> CID 1361275:(TAINTED_SCALAR)
>>> Passing tainted variable "subpart_dir_size()" to a tainted sink.
831 alloc_buffer(subpart_dir_buf, subpart_dir_size(), "Subpart 
Dir");
832 memcpy(buffer_get(subpart_dir_buf), , 
SUBPART_DIR_HEADER_SIZE);
833 
834 /* Read Subpart Dir entries. */
835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
836 struct subpart_dir_entry *e = _dir->e[0];
/util/cbfstool/ifwitool.c: 838 in parse_subpart_dir()
832 memcpy(buffer_get(subpart_dir_buf), , 
SUBPART_DIR_HEADER_SIZE);
833 
834 /* Read Subpart Dir entries. */
835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
836 struct subpart_dir_entry *e = _dir->e[0];
837 uint32_t i;
>>> CID 1361275:(TAINTED_SCALAR)
>>> Using tainted variable "hdr.num_entries" as a loop boundary.
838 for (i = 0; i < hdr.num_entries; i++) {
839 memcpy(e[i].name, data + offset, sizeof(e[i].name));
840 offset += sizeof(e[i].name);
841 offset = read_member(data, offset, sizeof(e[i].offset),
842  [i].offset);
843 offset = read_member(data, offset, sizeof(e[i].length),

** CID 1361274:  Insecure data handling  (TAINTED_SCALAR)



*** CID 1361274:  Insecure data handling  (TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 717 in alloc_bpdt_buffer()
711 {
712 struct bpdt_header bpdt_header;
713 assert((offset + BPDT_HEADER_SIZE) < size);
714 bpdt_read_header((uint8_t *)data + offset, _header, name);
715 
716 /* Buffer to read BPDT header and entries. */
>>> CID 1361274:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted variable "get_bpdt_size(_header)" to a tainted 
>>> sink.
717 alloc_buffer(b, get_bpdt_size(_header), name);
718 
719 struct bpdt *bpdt = buffer_get(b);
720 memcpy(>h, _header, BPDT_HEADER_SIZE);
721 
722 /*

** CID 1361253:  Memory - illegal accesses  (BUFFER_SIZE_WARNING)
/util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry()



*** CID 1361253:  Memory - illegal accesses  (BUFFER_SIZE_WARNING)
/util/cbfstool/ifwitool.c: 1300 in 

Re: [coreboot] Back to original BIOS

[Michal Widlok]

Hello Igor,

I've tried Yours procedure, but again no success. Anyway the bios
update was what make this board "unbootable" in the first place. I
think that I will just replace it with another one that is working
with original bios and with coreboot (again disassembly and soldering,
ufff).
Best Regards,
Michael Widlok

On Thu, Feb 9, 2017 at 2:11 PM, Igor Skochinsky  wrote:
>
>
>
>>Четверг,  9 февраля 2017, 12:16 +01:00 от Michal Widlok 
>>:
>>
>>Hello,
>>
>>Igor - I've checked it again. Mac is really at addresses 0x5F6000, 0x5F7000 - 
>>or my ghex editor does not work :-). The flash chip is 8MB (0x80), so 
>>fits right in. I will try Yours procedure, but I'm concerned about cutting 
>>image at 0x40 - are You talking about 4MB flash? All my laptops has 8MB.
>
> Ah, looks like you should use the files from the 7UET94WW directory, which 
> are 8MB for (unpacked) FL1 and 4MB for FL2 (you should use 20- 40 
> from it).
>
>>
>>Zoran - Michael is OK. In fact in polish Michal should end with special 
>>polish letter "ł", so I'm not sure if "international" Michael is not better 
>>anyway.
>>
>>Best Regards,
>>Michal Widlok
>>
>>
>>On Thu, Feb 9, 2017 at 9:50 AM, Zoran Stojsavljevic  < 
>>zoran.stojsavlje...@gmail.com > wrote:
>>>Hello Igor,
>>>
>>>Interesting emails. I should admit. For sure worth exploration, especially 
>>>GIT Hub application. :-)
>>>
>>>Michal (finally, I got your correct name, idiot me),
>>>
>>>I'll come back to this thread. I am last 3 days very busy. Very very busy, 
>>>but, certainly, I'll get free time, and will explore this opportunity, since 
>>>it makes my old, not so sharp anymore eyes very wide!
>>>
>>>Thank you all,
>>>Zoran
>>>
>>>On Wed, Feb 8, 2017 at 10:46 PM, Igor Skochinsky via coreboot  < 
>>>coreboot@coreboot.org > wrote:
P.S.


Hello Michal,

The T400 BIOS is in a Pre-UEFI Phoenix FFV format. You can use 
phoenix_extract.py[1] to extract modules from it.

To go back to Lenovo BIOS you can try the following:

1) download an update from lenovo (e.g. 7uuj49us.exe)
2) unpack it with innounp

2b) apparently innoextract [2] can be used on non-Windows platforms

[2]:  http://constexpr.org/innoextract/


3a) take the FL2 file (e.g. $01B8100.FL2),  cut out from 0x20 to 
0x40 and use the resulting image to replace coreboot in the BIOS region 
(end of flash).
3b) take the FL1 file  (e.g. $01B8100.FL1), unpack it with bcpvd from [1] 
and flash the result (it's a complete flash image with descriptor and ME) 
after cutting it at 0x40
4) according to the descriptor in unpacked FL1 , the GbE region is at 
001F6000 - 001F7FFF, so that's the most likely place for storing the MAC 
address. I'm not sure why your desc.rom lists 5F6000 - 005F7FFF... I think 
that's outside the flash chip.

[1]:  https://github.com/coreboot/bios_extract

--
WBR,
 Igor mailto:rox...@skynet.be



--
WBR,
 Igor mailto:skochin...@mail.ru
--
coreboot mailing list:  coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>--
>>coreboot mailing list:  coreboot@coreboot.org
>>https://www.coreboot.org/mailman/listinfo/coreboot
>
> WBR, Igor
> mailto:skochin...@mail.ru

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Coreboot support for Apollo Lake

[Tahnia Lichtenstein]

Hi there,

I am new to coreboot (and Intel Atom development), so please excuse me if I
ask clumsy questions...

I am tasked to get a bootloader (including the whole firmware stack)
running on a custom developed Intel Atom Apollo Lake board, loading Windows
10 IoT Enterprise. So I want to use coreboot for this (probably along with
either SeaBIOS or Tianocore).

However, I am still waiting to receive an Intel Apollo Lake CRB, so I do
not yet have access to the sample code that comes with the CRB. This also
means I can't yet try to load the currently available coreboot project for
Apollo Lake RVP.

It seems like the coreboot code for the Apollo Lake RVP is very bare bones.
Will this code work on a CRB as is, or is there a lot of extra development
I would need to do myself to get it running? If there is a lot of
development work to be done, then is the coreboot community looking at
doing this in the nearby future?

Otherwise, if I need to do the remaining development, is it going to be
mostly integration work in the sense that I need to copy code from the
Apollo Lake SoC project into the RVP project? Or will it mostly be new
development like configuring the correct interfaces, drivers, etc?

Best regards,
Tahnia
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot