the following patch was just integrated into master:
commit 49fcd75564e8308d695cf44f54e0e92d693df69b
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Tue Jan 29 03:16:20 2013 +0800
cbfstool: Fix incorrect CBFS free space by old cbfstool.
Old cbfstool may produce CBFS image with calculation error in size of last empty
entry, and then corrupts master header data when you really use every bit in
last entry. This fix will correct free space size when you load ROM images with
cbfs_image_from_file.
Change-Id: I2ada319728ef69ab9296ae446c77d37e05d05fce
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2211
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Mon Feb 4 23:46:55 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Tue Feb 5 22:25:46 2013, giving +2
See http://review.coreboot.org/2211 for details.
-gerrit
the following patch was just integrated into master:
commit c03d9b0c4387f7218e6c9c7d94cf86a5e2b3943e
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Tue Jan 29 02:38:40 2013 +0800
cbfstool: Use cbfs_image API for "remove" command.
To delete a component (file) from existing CBFS ROM image.
To test:
cbfstool coreboot.rom remove -n fallback/romstage
# and compare with old cbfstool output result.
Change-Id: If39ef9be0b34d8e3df77afb6c9f944e02f08bc4e
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2208
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Tue Feb 5 00:01:41 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Tue Feb 5 22:25:30 2013, giving +2
See http://review.coreboot.org/2208 for details.
-gerrit
the following patch was just integrated into master:
commit 0f8af71f1a40e8ae960ba616cb9a5bf14f10fb13
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Tue Jan 29 02:29:49 2013 +0800
cbfstool: Use cbfs_image API for "extract" command.
Change the "extract" command to use cbfs_export_entry API. Nothing changed in
its usage.
To verify, run "cbfstool coreboot.rom extract -f blah -n blah" and check if the
raw type file is correctly extracted.
Change-Id: I1ed280d47a2224a9d1213709f6b459b403ce5055
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2207
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Mon Feb 4 23:40:12 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Tue Feb 5 22:25:20 2013, giving +2
See http://review.coreboot.org/2207 for details.
-gerrit
the following patch was just integrated into master:
commit 3bb035b095a0e4144adfa55fa45b2332e3a6c7d5
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Tue Jan 29 02:15:49 2013 +0800
cbfstool: Use cbfs_image API for "print" command.
Process CBFS ROM image by new cbfs_image API.
To verify, run "cbfstool coreboot.rom print -v" and compare with old cbfstool.
Change-Id: I3a5a9ef176596d825e6cdba28a8ad732f69f5600
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2206
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Mon Feb 4 23:25:44 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Tue Feb 5 22:25:13 2013, giving +2
See http://review.coreboot.org/2206 for details.
-gerrit
the following patch was just integrated into master:
commit eab2c81949c8859892443c1e71449f391bc52d97
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Tue Jan 29 01:56:17 2013 +0800
cbfstool: Add cbfs_image new CBFS image manipulation API.
Current cbfstool implementation is relying on global variables to pass processed
data, and the calculation of address is based on x86 architecture (ex, always
assuming 0x0000 as invalid address), not easy to be used on platforms without
top-aligned memory mapping. This CL is a first step to start a new cbfstool
without global variables, and to prevent assuming memory layout in x86 mode.
The first published APIs are for reading and writing existing CBFS ROM image
files (and to find file entries in a ROM file).
Read cbfs_image.h for detail usage of each API function.
Change-Id: I28c737c8f290e51332119188248ac9e28042024c
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2194
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Mon Feb 4 23:54:27 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Tue Feb 5 22:25:02 2013, giving +2
See http://review.coreboot.org/2194 for details.
-gerrit
the following patch was just integrated into master:
commit 3cfacbf1961accff8670997368b403d8068ad94c
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Wed Jan 30 00:43:46 2013 +0800
cbfstool: Add buffer management API.
Many functions in cbfstool need to deal with a memory buffer - both location and
size. Right now it's made by different ways: for ROM image using global variable
(romsize, master_header); and in cbfs-* using return value for size and char**
to return memory location.
This may cause bugs like assuming incorrect return types, ex:
uint32_t file_size = parse(); // which returns "-1" on error
if (file_size <= 0) { ...
And the parse error will never be caught.
We can simplify this by introducing a buffer API, to change
unsigned int do_something(char *input, size_t len, char **output, ...)
into
int do_something(struct buffer *input, struct buffer *output, ...)
The buffer API will be used by further commits.
Change-Id: Iaddaeb109f08be6be84c6728d72c6a043b0e7a9f
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2205
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Mon Feb 4 23:18:18 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Tue Feb 5 22:24:45 2013, giving +2
See http://review.coreboot.org/2205 for details.
-gerrit
Thanks Антон,
I'm having a problem when I try to read your chart. I'm sure it is my fault
and probably makes more sense to someone more knowledgeable about modern
hardware, but at the same time someone like me should able to get basic
understanding. My problems are:
1. I am seeing many components and clearly some of them are hardware and
others are software blocks. It would be nice if we can use some kind of
convention to distinguish between the two.
2. I am not sure where the beginning of the chart is. I see label "POWER
ON", but looked from beginners eyes it looks like the SPI chip is
responsible to power on the "BP starts".
3. You are using many different colours and pattern lines, but I don't see
a legend what different line represent. Is it electrical signal, software
call, data flow and etc.
I'm looking forward to become helpful hand for coreboot project and your
work is going to be invaluable for me to understand the 'black magic' of
modern hardware.
On Mon, Feb 4, 2013 at 12:40 AM, Антон Кочков <anton.kochkov(a)gmail.com>wrote:
> Hello!
> Here is simple diagram for booting flow of modern Intel laptops. Feel
> free to ask questions, request for improvements, giving hints.
> Why Intel? Just because it is more complex than modern AMD systems.
> Why laptop? Same reason - more complex than desktop.
> If you have an idea howto merge laptop and desktop booting in one
> diagram - please share.
> Attaching both png result and MS Visio 2010 source.
>
> Best regards,
> Anton Kochkov.
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
How about SCaLEx11, is anyone from coreboot going to be at SCaLEx11?
On Sun, Feb 3, 2013 at 10:14 AM, ron minnich <rminnich(a)gmail.com> wrote:
> great booth!
>
> ron
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
A new version of spkmodem. This one doesn't lose the bit sync even if I
disconnect the cable for the short time (but, of course data sent when
no cable is attached is lost)
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko