dasharo/coreboot
0
0
Fork 0
mirror of https://github.com/Dasharo/coreboot.git synced 2026-06-13 10:16:48 -07:00
Code Issues Packages Projects Releases Wiki Activity

Since some people disapprove of white space cleanups mixed in regular commits

Browse Source 
while others dislike them being extra commits, let's clean them up once and
for all for the existing code. If it's ugly, let it only be ugly once :-)

Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>



git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This commit is contained in:
Stefan Reinauer
2010-04-27 06:56:47 +00:00
committed by Stefan Reinauer
parent 0e1e8065e3
commit 14e2277962
1022 changed files with 9209 additions and 9210 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Makefile
+3 -3
View File
@@ -161,7 +161,7 @@ $(obj)/config.h:
CBFSTOOL:=$(objutil)/cbfstool/cbfstool
# needed objects that every mainboard uses
# needed objects that every mainboard uses
# Creation of these is architecture and mainboard independent
$(obj)/mainboard/$(MAINBOARDDIR)/static.c: $(src)/mainboard/$(MAINBOARDDIR)/devicetree.cb $(objutil)/sconfig/sconfig
@printf " SCONFIG $(subst $(src)/,,$(<))\n"
@@ -282,14 +282,14 @@ printcrt0s:
@echo ldscripts=$(ldscripts)
OBJS := $(patsubst %,$(obj)/%,$(TARGETS-y))
INCLUDES := -Isrc -Isrc/include -I$(obj) -Isrc/arch/$(ARCHDIR-y)/include
INCLUDES := -Isrc -Isrc/include -I$(obj) -Isrc/arch/$(ARCHDIR-y)/include
INCLUDES += -Isrc/devices/oprom/include
# abspath is a workaround for romcc
INCLUDES += -include $(abspath $(obj)/config.h)
CFLAGS = $(INCLUDES) -Os -nostdinc -pipe
CFLAGS += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs
CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs
CFLAGS += -Wstrict-aliasing -Wshadow
ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y)
CFLAGS += -Werror
documentation/Kconfig.tex
+2 -2
View File
@@ -120,7 +120,7 @@ $(obj)/ssdt3.c: $(src)/mainboard/$(MAINBOARDDIR)/dx/pci3.asl"
iasl -p $(CURDIR)/pci3 -tc $(CONFIG_MAINBOARD)/
perl -pi -e 's/AmlCode/AmlCode_ssdt3/g' pci3.hex
mv pci3.hex ssdt3.c
$(obj)/ssdt4.c: $(src)/mainboard/$(MAINBOARDDIR)/dx/pci4.asl"
iasl -p $(CURDIR)/pci4 -tc $(CONFIG_MAINBOARD)/dx/pci4.asl
perl -pi -e 's/AmlCode/AmlCode_ssdt4/g' pci4.hex
@@ -470,7 +470,7 @@ we don't need to test for the chipset CONFIG variable. We
can therefore test other variables (which is part of the reason
we set up conditional inclusion of this file, instead
of unconditionally including it). Here is an example from AMD 8111.
No conditionals in this one yet.
No conditionals in this one yet.
\begin{verbatim}
driver-y += amd8111.o
driver-y += amd8111_usb.o
documentation/LinuxBIOS-AMD64.tex
+97 -97
View File
File diff suppressed because it is too large Load Diff
documentation/Makefile
+1 -1
View File
@@ -31,7 +31,7 @@ else ifneq ($(strip $(CONVERT)),)
convert $< $@
endif
LinuxBIOS-AMD64.toc: $(FIGS) LinuxBIOS-AMD64.tex
LinuxBIOS-AMD64.toc: $(FIGS) LinuxBIOS-AMD64.tex
# 2 times to make sure we have a current toc.
$(PDFLATEX) LinuxBIOS-AMD64.tex
$(PDFLATEX) LinuxBIOS-AMD64.tex
documentation/RFC/chip.tex
+77 -77
View File
@@ -2,17 +2,17 @@
\begin{abstract}
At the end of this document is the original message that motivated the
change.
change.
\end{abstract}
\section{Scope}
This document defines how LinuxBIOS programmers can specify chips that
are used, specified, and initalized. The current scope is for superio
chips, but the architecture should allow for specification of other chips such
as southbridges. Multiple chips of same or different type are supported.
are used, specified, and initalized. The current scope is for superio
chips, but the architecture should allow for specification of other chips such
as southbridges. Multiple chips of same or different type are supported.
\section{Goals}
The goals of the new chip architecture are these:
The goals of the new chip architecture are these:
\begin{itemize}
\item seperate implementation details from specification in the Config file
(translation: no more C code in Config files)
@@ -27,33 +27,33 @@ The specification looks like this:
\begin{verbatim}
chip <name> [path=<path>] ["<configuration>"]
\end{verbatim}
The name is in the standard LinuxBIOS form of type/vendor/name, e.g.
"southbridge/intel/piix4e" or "superio/ite/it8671f". The class of the
chip is derived from the first pathname component of the name, and the chip
configuration is derived from the following components.
The name is in the standard LinuxBIOS form of type/vendor/name, e.g.
"southbridge/intel/piix4e" or "superio/ite/it8671f". The class of the
chip is derived from the first pathname component of the name, and the chip
configuration is derived from the following components.
The path defines the access mechanism to the chip.
It is optional. If present, it overrides the default path to the chip.
The path defines the access mechanism to the chip.
It is optional. If present, it overrides the default path to the chip.
The configuration defines chip-specific configuration details, and is also
optional. Note that an empty configuration will leave the chip with
no enabled resources. This may be desirable in some cases.
optional. Note that an empty configuration will leave the chip with
no enabled resources. This may be desirable in some cases.
\section{Results of specifying a chip}
When one or more chips are specified, the data about the chips
is saved until the entire file is parsed. At this point, the config tool
creates a file in the build directory called chip.c This file contains
a common struct containing information about
each individual chip and an array of pointers to these structures.
a common struct containing information about
each individual chip and an array of pointers to these structures.
For each chip, there are two structures. The structures contain control
information for the chip, and register initialization information. The
names of the structures are derived by ``flattening'' the chip name,
as in the current linuxbios. For example, superio/ite/xyz uses
For each chip, there are two structures. The structures contain control
information for the chip, and register initialization information. The
names of the structures are derived by ``flattening'' the chip name,
as in the current linuxbios. For example, superio/ite/xyz uses
two structs, one called superio_ite_xyz_control and one called
superio_ite_xyz_init. The control struct is initialized from the
chip name and path information, and has a pointer to the
superio_ite_xyz_init. The control struct is initialized from the
chip name and path information, and has a pointer to the
config struct. The config struct is initialized from the quote string
\begin{verbatim}
@@ -64,29 +64,29 @@ To: linuxbios@clustermatic.org
Subject: RFC:new superio proposal
Abstract:
The superio architecture for linuxbios has worked for the last 2
years but is being stretched to the limit by the changes in superio chips.
The architecture depended on superio resources being relatively constant
between chips, but this assumption no longer holds. In this document we
propose several alternatives and solicit comments.
The superio architecture for linuxbios has worked for the last 2
years but is being stretched to the limit by the changes in superio chips.
The architecture depended on superio resources being relatively constant
between chips, but this assumption no longer holds. In this document we
propose several alternatives and solicit comments.
Overview:
The superio architecture in linuxbios was developed over time, and
modified as circumstances required. In the beginning it was relatively
simple and assumed only one superio per mainboard. The latest version
The superio architecture in linuxbios was developed over time, and
modified as circumstances required. In the beginning it was relatively
simple and assumed only one superio per mainboard. The latest version
allows an arbitrary number of superios per mainboard, and allows complete
specification of the superio base I/O address along with the specification
of reasonable default valures for both the base I/O address and the
superio parameters such as serial enable, baud rate, and so on.
of reasonable default valures for both the base I/O address and the
superio parameters such as serial enable, baud rate, and so on.
Specification of superio control parameters is done by a configuration
Specification of superio control parameters is done by a configuration
line such as:
nsuperio sis/950 com1={1} floppy=1 lpt=1
This fragment sets the superio type to sis/950; sets com1, floppy, and lpt
to enabled; and leaves the defaults to com1 (baud rate, etc.) to the
default values.
This fragment sets the superio type to sis/950; sets com1, floppy, and lpt
to enabled; and leaves the defaults to com1 (baud rate, etc.) to the
default values.
While it is not obvious, these configuration parameters are fragments of a
C initializer. The initializers are used to build a statically initialized
@@ -96,7 +96,7 @@ struct superio {
struct superio_control *super; // the ops for the device.
unsigned int port; // if non-zero, overrides the default port
// com ports. This is not done as an array (yet).
// We think it's easier to set up from python if it is not an
// We think it's easier to set up from python if it is not an
// array.
struct com_ports com1, com2, com3, com4;
// DMA, if it exists.
@@ -114,14 +114,14 @@ struct superio {
These structures are, in turn, created and statically initialized by a
config-tool-generated structure that defines all the superios. This file
is called nsuperio.c, is created for each mainboard you build, only
is called nsuperio.c, is created for each mainboard you build, only
appears in the build directory, and looks like this:
===
extern struct superio_control superio_winbond_w83627hf_control;
extern struct superio_control superio_winbond_w83627hf_control;
struct superio superio_winbond_w83627hf= {
&superio_winbond_w83627hf_control,
struct superio superio_winbond_w83627hf= {
&superio_winbond_w83627hf_control,
.com1={1}, .com2={1}, .floppy=1, .lpt=1, .keyboard=1, .hwmonitor=1};
struct superio *all_superio[] = {&superio_winbond_w83627hf,
@@ -131,12 +131,12 @@ unsigned long nsuperio = 1;
===
This example shows a board with one superio (nsuperio). The superio
consists of a winbond w83627hf, with com1, com2, floppy, lpt, keyboard,
and hwmonitor enabled. Note that this structure also allows for
over-riding the default superio base, although that capability is rarely
used.
consists of a winbond w83627hf, with com1, com2, floppy, lpt, keyboard,
and hwmonitor enabled. Note that this structure also allows for
over-riding the default superio base, although that capability is rarely
used.
The control structure is used to define how to access the superio for
The control structure is used to define how to access the superio for
purposes of control. It looks like this:
===
struct superio_control {
@@ -151,13 +151,13 @@ struct superio_control {
};
===
There are three methods for stages of hardwaremain. First is pre_pci_init
(for chips like the acer southbridge that require you to enable some
resources BEFORE pci scan); init, called during the 'middle' phase of
hardwaremain; and finishup, called before the payload is loaded.
There are three methods for stages of hardwaremain. First is pre_pci_init
(for chips like the acer southbridge that require you to enable some
resources BEFORE pci scan); init, called during the 'middle' phase of
hardwaremain; and finishup, called before the payload is loaded.
This approach was inspired by and borrows heavily on the Plan 9 kernel
configuration tools.
This approach was inspired by and borrows heavily on the Plan 9 kernel
configuration tools.
The problem:
@@ -166,22 +166,22 @@ smaller. It has grown and in the limit this structure is the union of all
possibly superio chips. Obviously, in the long term, this is not
practical: we can not anticipate all possible superio chips for all time.
The common PC BIOS solution to this type of problem is to continue with
binary structures but add version numbers to them, so that all code that
uses a given structure has to check the version number. Personally, I find
this grotesque and would rather not work this way.
The common PC BIOS solution to this type of problem is to continue with
binary structures but add version numbers to them, so that all code that
uses a given structure has to check the version number. Personally, I find
this grotesque and would rather not work this way.
Using textual strings for configuration is something I find far more
attractive. Plan 9 has shown that this approach has no real limits and
suffices for configuration tasks. The Linux kernel does more limited use
of strings for configuration, but still depends on them. Strings are
easier to read and work with than binary structures, and more important, a
lot easier to deal with when things start going wrong.
Using textual strings for configuration is something I find far more
attractive. Plan 9 has shown that this approach has no real limits and
suffices for configuration tasks. The Linux kernel does more limited use
of strings for configuration, but still depends on them. Strings are
easier to read and work with than binary structures, and more important, a
lot easier to deal with when things start going wrong.
The proposed solution:
What follows are three possible ideas for specifying superio resources and
their settings.
What follows are three possible ideas for specifying superio resources and
their settings.
A common part of the new idea is to eliminate the common superio
structure, due to the many variations in chips, and make it invisible
@@ -203,9 +203,9 @@ struct superio_control {
char *name;
};
I.e. we add a new function for creating the superio.
I.e. we add a new function for creating the superio.
Communication of superio settings from linuxbios to the superio would be
Communication of superio settings from linuxbios to the superio would be
via textual strings. The superio structure becomes this:
struct superio {
@@ -215,7 +215,7 @@ struct superio {
};
So now the question becomes, what is the configuration structure?
So now the question becomes, what is the configuration structure?
There are several choices. The simplest, from my point of view, are
keyword-value pairs:
struct configuration {
@@ -223,11 +223,11 @@ struct configuration {
const char *value;
};
These get filled in by the config tool as before. The linuxbios libary can
then provide a generic parsing function for the superios to use.
These get filled in by the config tool as before. The linuxbios libary can
then provide a generic parsing function for the superios to use.
The remaining question is how should the superio command look in
freebios2?
The remaining question is how should the superio command look in
freebios2?
superio sis/950 "com1=115200,8n1 lpt=1 com2=9600"
@@ -242,22 +242,22 @@ superio sis/950 ((com1 115200 8n1) (lpt 1))
So, my questions:
1. Does this new scheme look workable. If not, what needs to change?
2. What should the 'struct configuration' be? does keyword/value work?
3. what should the superio command look like?
2. What should the 'struct configuration' be? does keyword/value work?
3. what should the superio command look like?
Comments welcome.
I'd like to adopt this "RFC" approach for freebios2 as much as we can.
I'd like to adopt this "RFC" approach for freebios2 as much as we can.
There was a lot of give-and-take in the early days of linuxbios about
structure and it proved useful. There's a lot that will start happening in
freebios2 now, and we need to try to make sure it will work for everyone.
Those of you who are doing mainboards, please look at freebios2 and see
how it looks for you. There's a lot of good work that has been done (not
by me so far, thanks Eric and Stefan), and more that needs to be done.
Consider trying out romcc as an "assembly code killer". See how it fits
together and if you can work with it or need changes. Bring comments back
to this list.
by me so far, thanks Eric and Stefan), and more that needs to be done.
Consider trying out romcc as an "assembly code killer". See how it fits
together and if you can work with it or need changes. Bring comments back
to this list.
thanks
documentation/RFC/config.tex
+31 -31
View File
@@ -8,7 +8,7 @@ We describe the new configuration language for LinuxBIOS.
This document defines the new configuration language for LinuxBIOS.
\section{Goals}
The goals of the new language are these:
The goals of the new language are these:
\begin{itemize}
\item Simplified Makefiles so people can see what is set
\item Move from the regular-expression-based language to something
@@ -16,22 +16,22 @@ a bit more comprehensible and flexible
\item make the specification easier for people to use and understand
\item allow unique register-set-specifiers for each chip
\item allow generic register-set-specifiers for each chip
\item generate static initialization code, as needed, for the
specifiers.
\item generate static initialization code, as needed, for the
specifiers.
\end{itemize}
\section{Language}
Here is the new language. It is very similar to the old one, differing
in only a few respects. It borrows heavily from Greg Watson's suggestions.
in only a few respects. It borrows heavily from Greg Watson's suggestions.
I am presenting it in a pseudo-BNF in the hopes it will be easier. Things
in '' are keywords; things in ``'' are strings in the actual text.
I am presenting it in a pseudo-BNF in the hopes it will be easier. Things
in '' are keywords; things in ``'' are strings in the actual text.
\begin{verbatim}
#exprs are composed of factor or factor + factor etc.
expr ::= factor ( ``+'' factor | ``-'' factor | )*
#factors are term or term * term or term / term or ...
factor ::= term ( ``*'' term | ``/'' term | ... )*
#
#
unary-op ::= ``!'' ID
# term is a number, hexnumber, ID, unary-op, or a full-blown expression
term ::= NUM | XNUM | ID | unary-op | ``(`` expr ``)''
@@ -39,27 +39,27 @@ term ::= NUM | XNUM | ID | unary-op | ``(`` expr ``)''
# Option command. Can be an expression or quote-string.
# Options are used in the config tool itself (in expressions and 'if')
# and are also passed to the C compiler when building linuxbios.
# It is an error to have two option commands in a file.
# It is an error to have two option commands in a file.
# It is an error to have an option command after the ID has been used
# in an expression (i.e. 'set after used' is an error)
option ::= 'option' ID '=' (``value'' | term)
# Default command. The ID is set to this value if no option command
# is scanned.
# Multiple defaults for an ID will produce warning, but not errors.
# is scanned.
# Multiple defaults for an ID will produce warning, but not errors.
# It is OK to scan a default command after use of an ID.
# Options always over-ride defaults.
default ::= 'default' ID '=' (``value'' | term)
# the mainboard, southbridge, northbridge commands
# cause sourcing of Config.lb files as in the old config tool
# as parts are sourced, a device tree is built. The structure
# as parts are sourced, a device tree is built. The structure
# of the tree is determined by the structure of the components
# as they are specified. To attach a superio to a southbridge, for
# example, one would do this:
# southbridge acer/5432
# superio nsc/123
# end
# southbridge acer/5432
# superio nsc/123
# end
# end
# the tool generates static initializers for this hierarchy.
@@ -79,17 +79,17 @@ register ::= 'register' ``CODE''
mainboard ::= 'mainboard' PATH (statements)* 'end'
# standard linuxbios commands
southbridge ::= 'southbridge' PATH (statemnts)* 'end'
northbridge ::= 'northbridge' PATH (statemnts)* 'end'
superio ::= 'superio PATH (statemnts)* 'end'
cpu ::= 'cpu' PATH (statemnts)* 'end'
arch ::= 'arch' PATH (statemnts)* 'end'
southbridge ::= 'southbridge' PATH (statemnts)* 'end'
northbridge ::= 'northbridge' PATH (statemnts)* 'end'
superio ::= 'superio PATH (statemnts)* 'end'
cpu ::= 'cpu' PATH (statemnts)* 'end'
arch ::= 'arch' PATH (statemnts)* 'end'
# files for building linuxbios
# include a file in crt0.S
mainboardinit ::= 'mainboardinit' PATH
# include a file in crt0.S
mainboardinit ::= 'mainboardinit' PATH
# object file
# object file
object ::= 'object' PATH
# driver objects are just built into the image in a different way
driver ::= 'driver' PATH
@@ -116,7 +116,7 @@ makedefine ::= 'makedefine' ``RAWTEXT''
addaction ::= 'addaction' PATH ``ACTION''
# statements
statement ::=
statement ::=
option
| default
| cpu
@@ -204,12 +204,12 @@ ldscript cpu/i386/entry32.lds
###
### Build our reset vector (This is where linuxBIOS is entered)
###
if CONFIG_USE_FALLBACK_IMAGE
mainboardinit cpu/i386/reset16.inc
ldscript cpu/i386/reset16.lds
if CONFIG_USE_FALLBACK_IMAGE
mainboardinit cpu/i386/reset16.inc
ldscript cpu/i386/reset16.lds
else
mainboardinit cpu/i386/reset32.inc
ldscript cpu/i386/reset32.lds
mainboardinit cpu/i386/reset32.inc
ldscript cpu/i386/reset32.lds
end
.
.
@@ -227,7 +227,7 @@ makerule ./auto.inc dep "./romcc ./auto.E" act "./romcc -O ./auto.E > auto.inc"
mainboardinit ./auto.inc
#
###
### Include the secondary Configuration files
### Include the secondary Configuration files
###
northbridge amd/amdk8
end
@@ -286,6 +286,6 @@ export CC:=$(CONFIG_CROSS_COMPILE)gcc
\end{verbatim}
In other words, instead of expressions, we see the values. It's easier to
deal with.
In other words, instead of expressions, we see the values. It's easier to
deal with.
documentation/cbfs.txt
+47 -47
View File
@@ -4,71 +4,71 @@ Received: from www.crouse-house.com ([199.45.160.146]
From: Jordan Crouse <jordan@cosmicpenguin.net>
Greetings. I apologize for the incompleteness of what I am about to
discuss. I was planning on working on it leisurely, but my employment
circumstances changed and I've been trying to get it completed in a
Greetings. I apologize for the incompleteness of what I am about to
discuss. I was planning on working on it leisurely, but my employment
circumstances changed and I've been trying to get it completed in a
hurry before I had to leave it behind.
I've been thinking a lot about LAR lately, and ways to make it more
extensible and robust. Marc and I have been trading ideas back and
forth for a number of months, and over time a clear idea of what I
I've been thinking a lot about LAR lately, and ways to make it more
extensible and robust. Marc and I have been trading ideas back and
forth for a number of months, and over time a clear idea of what I
wanted to do started to take shape.
My goal was to add small things to LAR while retaining the overall
scheme. Over time, the scheme evolved slightly, but I think you'll find
that it remains true to the original idea. Below is the beginnings of
an architecture document - I did it in text form, but if met with
aclaim, it should be wikified. This presents what I call CBFS - the
next generation LAR for next generation Coreboot. Its easier to
My goal was to add small things to LAR while retaining the overall
scheme. Over time, the scheme evolved slightly, but I think you'll find
that it remains true to the original idea. Below is the beginnings of
an architecture document - I did it in text form, but if met with
aclaim, it should be wikified. This presents what I call CBFS - the
next generation LAR for next generation Coreboot. Its easier to
describe what it is by describing what changed:
A header has been added somewhere in the bootblock similar to Carl
Daniel's scheme. In addition to the coreboot information, the header
reports the size of the ROM, the alignment of the blocks, and the offset
of the first component in the CBFS. The master header provides all
A header has been added somewhere in the bootblock similar to Carl
Daniel's scheme. In addition to the coreboot information, the header
reports the size of the ROM, the alignment of the blocks, and the offset
of the first component in the CBFS. The master header provides all
the information LAR needs plus the magic number information flashrom needs.
Each "file" (or component, as I style them) now has a type associated
with it. The type is used by coreboot to identify the type of file that
it is loading, and it can also be used by payloads to group items in the
Each "file" (or component, as I style them) now has a type associated
with it. The type is used by coreboot to identify the type of file that
it is loading, and it can also be used by payloads to group items in the
CBFS by type (i.e - bayou can ask for all components that are payloads).
The header on each "file" (or component, as I like to style them) has
been simplified - We now only store the length, the type, the checksum,
and the offset to the data. The name scheme remains the same. The
addtional information, which is component specific, has been moved to
The header on each "file" (or component, as I like to style them) has
been simplified - We now only store the length, the type, the checksum,
and the offset to the data. The name scheme remains the same. The
addtional information, which is component specific, has been moved to
the component itself (see below).
The components are arranged in the ROM aligned along the specified
The components are arranged in the ROM aligned along the specified
alignment from the master header - this is to facilitate partial re-write.
Other then that, the LAR ideas remain pretty much the same.
The plan for moving the metadata to the components is to allow many
different kinds of components, not all of which are groked by coreboot.
However, there are three essential component types that are groked by
The plan for moving the metadata to the components is to allow many
different kinds of components, not all of which are groked by coreboot.
However, there are three essential component types that are groked by
coreboot, and they are defined:
stage - the stage is being parsed from the original ELF, and stored in
the ROM as a single blob of binary data. The load address, start
stage - the stage is being parsed from the original ELF, and stored in
the ROM as a single blob of binary data. The load address, start
address, compression type and length are stored in the component sub-header.
payload - this is essentially SELF in different clothing - same idea as
payload - this is essentially SELF in different clothing - same idea as
SELF, with the sub-header as above.
optionrom - This is in flux - right now, the optionrom is stored
optionrom - This is in flux - right now, the optionrom is stored
unadulterated and uncompressed, but that is likely to be changed.
Following this email are two replies containing the v3 code and a new
ROM tool to implement this respectively. I told you that I was trying
to get this out before I disappear, and I'm not kidding - the code is
compile tested and not run-tested. I hope that somebody will embrace
this code and take it the rest of the way, otherwise it will die a
Following this email are two replies containing the v3 code and a new
ROM tool to implement this respectively. I told you that I was trying
to get this out before I disappear, and I'm not kidding - the code is
compile tested and not run-tested. I hope that somebody will embrace
this code and take it the rest of the way, otherwise it will die a
pretty short death.
I realize that this will start an awesome flamewar, and I'm looking
forward to it. Thanks for listening to me over the years - and good
luck with coreboot. When you all make a million dollars, send me a few
I realize that this will start an awesome flamewar, and I'm looking
forward to it. Thanks for listening to me over the years - and good
luck with coreboot. When you all make a million dollars, send me a few
bucks, will you?
Jordan
@@ -152,7 +152,7 @@ struct cbfs_header {
The meaning of each member is as follows:
'magic' is a 32 bit number that identifies the ROM as a CBFS type. The
'magic' is a 32 bit number that identifies the ROM as a CBFS type. The
magic
number is 0x4F524243, which is 'ORBC' in ASCII.
@@ -160,7 +160,7 @@ number is 0x4F524243, which is 'ORBC' in ASCII.
0xFFFFFFFF to locate the beginning of the ROM in memory.
'align' is the number of bytes that each component is aligned to within the
ROM. This is used to make sure that each component is aligned correctly
ROM. This is used to make sure that each component is aligned correctly
with
regards to the erase block sizes on the ROM - allowing one to replace a
component at runtime without disturbing the others.
@@ -170,7 +170,7 @@ the ROM). This is to allow for arbitrary space to be left at the beginning
of the ROM for things like embedded controller firmware.
= Bootblock =
The bootblock is a mandatory component in the ROM. It is located in the
The bootblock is a mandatory component in the ROM. It is located in the
last
20k of the ROM space, and contains, among other things, the location of the
master header and the entry point for the loader firmware. The bootblock
@@ -179,11 +179,11 @@ does not have a component header attached to it.
= Components =
CBFS components are placed in the ROM starting at 'offset' specified in
the master header and ending at the bootblock. Thus the total size
the master header and ending at the bootblock. Thus the total size
available
for components in the ROM is (ROM size - 20k - 'offset'). Each CBFS
component is to be aligned according to the 'align' value in the header.
Thus, if a component of size 1052 is located at offset 0 with an 'align'
Thus, if a component of size 1052 is located at offset 0 with an 'align'
value
of 1024, the next component will be located at offset 2048.
@@ -214,12 +214,12 @@ below.
'checksum' is a 32bit checksum of the entire component, including the
header and name.
'offset' is the start of the component data, based off the start of the
'offset' is the start of the component data, based off the start of the
header.
The difference between the size of the header and offset is the size of the
component name.
Immediately following the header will be the name of the component,
Immediately following the header will be the name of the component,
which will
null terminated and 16 byte aligned. The following picture shows the
structure of the header:
@@ -248,7 +248,7 @@ component was found.
Upon recognizing a component, the software then has to search for the
specific name of the component. This is accomplished by comparing the
desired name with the string on the component located at
offset + sizeof(struct cbfs_file). If the string matches, then the
offset + sizeof(struct cbfs_file). If the string matches, then the
component
has been located, otherwise the software should add 'offset' + 'len' to
the offset and resume the search for the magic value.
documentation/codeflow.svg
+7 -7
View File
@@ -97,7 +97,7 @@
<g>
<g>
<g>
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,31.246 130.359,46.62 132.854,44.7
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,31.246 130.359,46.62 132.854,44.7
132.027,51.206 131.201,57.711 124.701,56.845 118.201,55.98 120.608,54.127 110.178,33.439 "/>
</g>
<polygon fill="#231F20" points="131.101,57.636 132.228,59.101 133.828,45.178 133.062,44.181 "/>
@@ -117,7 +117,7 @@
<g>
<g>
<g>
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,81.246 130.359,96.62 132.854,94.7
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,81.246 130.359,96.62 132.854,94.7
132.027,101.206 131.201,107.711 124.701,106.845 118.201,105.98 120.608,104.127 110.178,83.439 "/>
</g>
<polygon fill="#231F20" points="131.101,107.636 132.228,109.101 133.828,95.178 133.062,94.181 "/>
@@ -137,7 +137,7 @@
<g>
<g>
<g>
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,151.586 130.359,166.961 132.854,165.041
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,151.586 130.359,166.961 132.854,165.041
132.027,171.546 131.201,178.052 124.701,177.186 118.201,176.321 120.608,174.468 110.178,153.78 "/>
</g>
<polygon fill="#231F20" points="131.101,177.977 132.228,179.442 133.828,165.519 133.062,164.522 "/>
@@ -157,7 +157,7 @@
<g>
<g>
<g>
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,227.013 130.359,242.387 132.854,240.467
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,227.013 130.359,242.387 132.854,240.467
132.027,246.973 131.201,253.478 124.701,252.612 118.201,251.747 120.608,249.894 110.178,229.207 "/>
</g>
<polygon fill="#231F20" points="131.101,253.403 132.228,254.868 133.828,240.945 133.062,239.948 "/>
@@ -177,7 +177,7 @@
<g>
<g>
<g>
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,303.013 130.359,318.388 132.854,316.468
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,303.013 130.359,318.388 132.854,316.468
132.027,322.973 131.201,329.479 124.701,328.612 118.201,327.747 120.607,325.895 110.178,305.207 "/>
</g>
<polygon fill="#231F20" points="131.101,329.404 132.228,330.868 133.829,316.945 133.062,315.948 "/>
@@ -197,7 +197,7 @@
<g>
<g>
<g>
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,395.872 130.359,411.247 132.854,409.327
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,395.872 130.359,411.247 132.854,409.327
132.027,415.833 131.201,422.338 124.701,421.473 118.201,420.606 120.608,418.754 110.178,398.066 "/>
</g>
<polygon fill="#231F20" points="131.101,422.264 132.228,423.728 133.828,409.805 133.062,408.808 "/>
@@ -217,7 +217,7 @@
<g>
<g>
<g>
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,452.152 130.359,467.528 132.854,465.608
<polygon fill="#FFFFFF" stroke="#231F20" stroke-width="0.3876" points="113.028,452.152 130.359,467.528 132.854,465.608
132.027,472.113 131.201,478.619 124.701,477.753 118.201,476.888 120.607,475.035 110.178,454.347 "/>
</g>
<polygon fill="#231F20" points="131.101,478.545 132.228,480.009 133.829,466.085 133.062,465.089 "/>
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 17 KiB

After

Width:  |  Height:  |  Size: 17 KiB

payloads/bayou/bayou.xml.example
+2 -2
View File
@@ -29,11 +29,11 @@
<chain>
<file>payloads/passwd.elf</file>
<lar>passwd</lar>
</chain>
</chain>
<chain>
<file>payloads/coreinfo.elf</file>
</chain>
</payload>
</payload>
<payload type="chooser">
<file>payloads/coreinfo.elf</file>
</payload>
payloads/bayou/lzmadecode.c
+20 -20
View File
@@ -1,21 +1,21 @@
/*
LzmaDecode.c
LZMA Decoder (optimized for Speed version)
LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
http://www.7-zip.org/
LZMA SDK is licensed under two licenses:
1) GNU Lesser General Public License (GNU LGPL)
2) Common Public License (CPL)
It means that you can select one of these two licenses and
It means that you can select one of these two licenses and
follow rules of that license.
SPECIAL EXCEPTION:
Igor Pavlov, as the author of this Code, expressly permits you to
statically or dynamically link your Code (or bind by name) to the
interfaces of this file without subjecting your linked Code to the
terms of the CPL or GNU LGPL. Any modifications or additions
Igor Pavlov, as the author of this Code, expressly permits you to
statically or dynamically link your Code (or bind by name) to the
interfaces of this file without subjecting your linked Code to the
terms of the CPL or GNU LGPL. Any modifications or additions
to this file, however, are subject to the LGPL or CPL terms.
*/
@@ -37,7 +37,7 @@
#define RC_TEST { if (Buffer == BufferLim) return LZMA_RESULT_DATA_ERROR; }
#define RC_INIT(buffer, bufferSize) Buffer = buffer; BufferLim = buffer + bufferSize; RC_INIT2
#define RC_NORMALIZE if (Range < kTopValue) { RC_TEST; Range <<= 8; Code = (Code << 8) | RC_READ_BYTE; }
@@ -47,9 +47,9 @@
#define RC_GET_BIT2(p, mi, A0, A1) IfBit0(p) \
{ UpdateBit0(p); mi <<= 1; A0; } else \
{ UpdateBit1(p); mi = (mi + mi) + 1; A1; }
#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)
{ UpdateBit1(p); mi = (mi + mi) + 1; A1; }
#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)
#define RangeDecoderBitTreeDecode(probs, numLevels, res) \
{ int i = numLevels; res = 1; \
@@ -72,7 +72,7 @@
#define LenLow (LenChoice2 + 1)
#define LenMid (LenLow + (kNumPosStatesMax << kLenNumLowBits))
#define LenHigh (LenMid + (kNumPosStatesMax << kLenNumMidBits))
#define kNumLenProbs (LenHigh + kLenNumHighSymbols)
#define kNumLenProbs (LenHigh + kLenNumHighSymbols)
#define kNumStates 12
@@ -161,7 +161,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
for (i = 0; i < numProbs; i++)
p[i] = kBitModelTotal >> 1;
}
RC_INIT(inStream, inSize);
@@ -170,7 +170,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
CProb *prob;
UInt32 bound;
int posState = (int)(
(nowPos
(nowPos
)
& posStateMask);
@@ -179,9 +179,9 @@ int LzmaDecode(CLzmaDecoderState *vs,
{
int symbol = 1;
UpdateBit0(prob)
prob = p + Literal + (LZMA_LIT_SIZE *
prob = p + Literal + (LZMA_LIT_SIZE *
(((
(nowPos
(nowPos
)
& literalPosMask) << lc) + (previousByte >> (8 - lc))));
@@ -212,7 +212,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
else if (state < 10) state -= 3;
else state -= 6;
}
else
else
{
UpdateBit1(prob);
prob = p + IsRep + state;
@@ -236,10 +236,10 @@ int LzmaDecode(CLzmaDecoderState *vs,
IfBit0(prob)
{
UpdateBit0(prob);
if (nowPos == 0)
return LZMA_RESULT_DATA_ERROR;
state = state < kNumLitStates ? 9 : 11;
previousByte = outStream[nowPos - rep0];
outStream[nowPos++] = previousByte;
@@ -261,7 +261,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
UpdateBit0(prob);
distance = rep1;
}
else
else
{
UpdateBit1(prob);
prob = p + IsRepG2 + state;
@@ -322,7 +322,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
int posSlot;
state += kNumLitStates;
prob = p + PosSlot +
((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) <<
((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) <<
kNumPosSlotBits);
RangeDecoderBitTreeDecode(prob, kNumPosSlotBits, posSlot);
if (posSlot >= kStartPosModelIndex)
payloads/bayou/lzmadecode.h
+6 -6
View File
@@ -1,4 +1,4 @@
/*
/*
LzmaDecode.h
LZMA Decoder interface
@@ -8,14 +8,14 @@
LZMA SDK is licensed under two licenses:
1) GNU Lesser General Public License (GNU LGPL)
2) Common Public License (CPL)
It means that you can select one of these two licenses and
It means that you can select one of these two licenses and
follow rules of that license.
SPECIAL EXCEPTION:
Igor Pavlov, as the author of this code, expressly permits you to
statically or dynamically link your code (or bind by name) to the
interfaces of this file without subjecting your linked code to the
terms of the CPL or GNU LGPL. Any modifications or additions
Igor Pavlov, as the author of this code, expressly permits you to
statically or dynamically link your code (or bind by name) to the
interfaces of this file without subjecting your linked code to the
terms of the CPL or GNU LGPL. Any modifications or additions
to this file, however, are subject to the LGPL or CPL terms.
*/
payloads/bayou/nrv2b.c
+2 -2
View File
@@ -1,6 +1,6 @@
#include <libpayload.h>
// This GETBIT is supposed to work on little endian
// This GETBIT is supposed to work on little endian
// 32bit systems. The algorithm will definitely need
// some fixing on other systems, but it might not be
// a problem since the nrv2b binary behaves the same..
@@ -40,7 +40,7 @@ unsigned long unrv2b(u8 *src, u8 *dst, unsigned long *ilen_p)
// skip length
src += 4;
/* FIXME: check olen with the length stored in first 4 bytes */
/* FIXME: check olen with the length stored in first 4 bytes */
for (;;) {
unsigned int m_off, m_len;
payloads/bayou/util/pbuilder/lzma/C/7zip/Decompress/LzmaDecode.c
+23 -23
View File
@@ -1,21 +1,21 @@
/*
LzmaDecode.c
LZMA Decoder (optimized for Speed version)
LZMA SDK 4.22 Copyright (c) 1999-2005 Igor Pavlov (2005-06-10)
http://www.7-zip.org/
LZMA SDK is licensed under two licenses:
1) GNU Lesser General Public License (GNU LGPL)
2) Common Public License (CPL)
It means that you can select one of these two licenses and
It means that you can select one of these two licenses and
follow rules of that license.
SPECIAL EXCEPTION:
Igor Pavlov, as the author of this Code, expressly permits you to
statically or dynamically link your Code (or bind by name) to the
interfaces of this file without subjecting your linked Code to the
terms of the CPL or GNU LGPL. Any modifications or additions
Igor Pavlov, as the author of this Code, expressly permits you to
statically or dynamically link your Code (or bind by name) to the
interfaces of this file without subjecting your linked Code to the
terms of the CPL or GNU LGPL. Any modifications or additions
to this file, however, are subject to the LGPL or CPL terms.
*/
@@ -50,7 +50,7 @@
#define RC_TEST { if (Buffer == BufferLim) return LZMA_RESULT_DATA_ERROR; }
#define RC_INIT(buffer, bufferSize) Buffer = buffer; BufferLim = buffer + bufferSize; RC_INIT2
#endif
#define RC_NORMALIZE if (Range < kTopValue) { RC_TEST; Range <<= 8; Code = (Code << 8) | RC_READ_BYTE; }
@@ -61,9 +61,9 @@
#define RC_GET_BIT2(p, mi, A0, A1) IfBit0(p) \
{ UpdateBit0(p); mi <<= 1; A0; } else \
{ UpdateBit1(p); mi = (mi + mi) + 1; A1; }
#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)
{ UpdateBit1(p); mi = (mi + mi) + 1; A1; }
#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)
#define RangeDecoderBitTreeDecode(probs, numLevels, res) \
{ int i = numLevels; res = 1; \
@@ -86,7 +86,7 @@
#define LenLow (LenChoice2 + 1)
#define LenMid (LenLow + (kNumPosStatesMax << kLenNumLowBits))
#define LenHigh (LenMid + (kNumPosStatesMax << kLenNumMidBits))
#define kNumLenProbs (LenHigh + kLenNumHighSymbols)
#define kNumLenProbs (LenHigh + kLenNumHighSymbols)
#define kNumStates 12
@@ -172,7 +172,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
int lc = vs->Properties.lc;
#ifdef _LZMA_OUT_READ
UInt32 Range = vs->Range;
UInt32 Code = vs->Code;
#ifdef _LZMA_IN_CB
@@ -214,7 +214,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
UInt32 numProbs = Literal + ((UInt32)LZMA_LIT_SIZE << (lc + vs->Properties.lp));
UInt32 i;
for (i = 0; i < numProbs; i++)
p[i] = kBitModelTotal >> 1;
p[i] = kBitModelTotal >> 1;
rep0 = rep1 = rep2 = rep3 = 1;
state = 0;
globalPos = 0;
@@ -265,7 +265,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
for (i = 0; i < numProbs; i++)
p[i] = kBitModelTotal >> 1;
}
#ifdef _LZMA_IN_CB
RC_INIT;
#else
@@ -279,7 +279,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
CProb *prob;
UInt32 bound;
int posState = (int)(
(nowPos
(nowPos
#ifdef _LZMA_OUT_READ
+ globalPos
#endif
@@ -291,9 +291,9 @@ int LzmaDecode(CLzmaDecoderState *vs,
{
int symbol = 1;
UpdateBit0(prob)
prob = p + Literal + (LZMA_LIT_SIZE *
prob = p + Literal + (LZMA_LIT_SIZE *
(((
(nowPos
(nowPos
#ifdef _LZMA_OUT_READ
+ globalPos
#endif
@@ -342,7 +342,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
else if (state < 10) state -= 3;
else state -= 6;
}
else
else
{
UpdateBit1(prob);
prob = p + IsRep + state;
@@ -369,14 +369,14 @@ int LzmaDecode(CLzmaDecoderState *vs,
UInt32 pos;
#endif
UpdateBit0(prob);
#ifdef _LZMA_OUT_READ
if (distanceLimit == 0)
#else
if (nowPos == 0)
#endif
return LZMA_RESULT_DATA_ERROR;
state = state < kNumLitStates ? 9 : 11;
#ifdef _LZMA_OUT_READ
pos = dictionaryPos - rep0;
@@ -412,7 +412,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
UpdateBit0(prob);
distance = rep1;
}
else
else
{
UpdateBit1(prob);
prob = p + IsRepG2 + state;
@@ -473,7 +473,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
int posSlot;
state += kNumLitStates;
prob = p + PosSlot +
((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) <<
((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) <<
kNumPosSlotBits);
RangeDecoderBitTreeDecode(prob, kNumPosSlotBits, posSlot);
if (posSlot >= kStartPosModelIndex)
@@ -528,7 +528,7 @@ int LzmaDecode(CLzmaDecoderState *vs,
len += kMatchMinLen;
#ifdef _LZMA_OUT_READ
if (rep0 > distanceLimit)
if (rep0 > distanceLimit)
#else
if (rep0 > nowPos)
#endif
payloads/bayou/util/pbuilder/lzma/C/7zip/Decompress/LzmaDecode.h
+7 -7
View File
@@ -1,4 +1,4 @@
/*
/*
LzmaDecode.h
LZMA Decoder interface
@@ -8,14 +8,14 @@
LZMA SDK is licensed under two licenses:
1) GNU Lesser General Public License (GNU LGPL)
2) Common Public License (CPL)
It means that you can select one of these two licenses and
It means that you can select one of these two licenses and
follow rules of that license.
SPECIAL EXCEPTION:
Igor Pavlov, as the author of this code, expressly permits you to
statically or dynamically link your code (or bind by name) to the
interfaces of this file without subjecting your linked code to the
terms of the CPL or GNU LGPL. Any modifications or additions
Igor Pavlov, as the author of this code, expressly permits you to
statically or dynamically link your code (or bind by name) to the
interfaces of this file without subjecting your linked code to the
terms of the CPL or GNU LGPL. Any modifications or additions
to this file, however, are subject to the LGPL or CPL terms.
*/
@@ -29,7 +29,7 @@
/* Use read function for output data */
/* #define _LZMA_PROB32 */
/* It can increase speed on some 32-bit CPUs,
/* It can increase speed on some 32-bit CPUs,
but memory usage will be doubled in that case */
/* #define _LZMA_LOC_OPT */
payloads/bayou/util/pbuilder/lzma/minilzma.cc
+29 -29
View File
@@ -89,7 +89,7 @@ static UInt32 SelectDictionarySizeFor(unsigned datasize)
if(datasize <= 512) return 512;
if(datasize <= 1024) return 1024;
if(datasize <= 4096) return 4096;
if(datasize <= 16384) return 32768;
if(datasize <= 16384) return 32768;
if(datasize <= 65536) return 528288;
if(datasize <= 528288) return 1048576*4;
if(datasize <= 786432) reutrn 1048576*16;
@@ -105,12 +105,12 @@ class CInStreamRam: public ISequentialInStream, public CMyUnknownImp
size_t Pos;
public:
MY_UNKNOWN_IMP
CInStreamRam(const std::vector<unsigned char>& buf) : input(buf), Pos(0)
{
}
virtual ~CInStreamRam() {}
STDMETHOD(Read)(void *data, UInt32 size, UInt32 *processedSize);
};
@@ -118,12 +118,12 @@ STDMETHODIMP CInStreamRam::Read(void *data, UInt32 size, UInt32 *processedSize)
{
UInt32 remain = input.size() - Pos;
if (size > remain) size = remain;
std::memcpy(data, &input[Pos], size);
Pos += size;
if(processedSize != NULL) *processedSize = size;
return S_OK;
}
@@ -133,27 +133,27 @@ class COutStreamRam: public ISequentialOutStream, public CMyUnknownImp
size_t Pos;
public:
MY_UNKNOWN_IMP
COutStreamRam(): result(), Pos(0) { }
virtual ~COutStreamRam() { }
void Reserve(unsigned n) { result.reserve(n); }
const std::vector<Byte>& Get() const { return result; }
HRESULT WriteByte(Byte b)
{
if(Pos >= result.size()) result.resize(Pos+1);
result[Pos++] = b;
return S_OK;
}
STDMETHOD(Write)(const void *data, UInt32 size, UInt32 *processedSize);
};
STDMETHODIMP COutStreamRam::Write(const void *data, UInt32 size, UInt32 *processedSize)
{
if(Pos+size > result.size()) result.resize(Pos+size);
std::memcpy(&result[Pos], data, size);
if(processedSize != NULL) *processedSize = size;
Pos += size;
@@ -163,15 +163,15 @@ STDMETHODIMP COutStreamRam::Write(const void *data, UInt32 size, UInt32 *process
const std::vector<unsigned char> LZMACompress(const std::vector<unsigned char>& buf)
{
if(buf.empty()) return buf;
const UInt32 dictionarysize = SelectDictionarySizeFor(buf.size());
NCompress::NLZMA::CEncoder *encoderSpec = new NCompress::NLZMA::CEncoder;
CMyComPtr<ICompressCoder> encoder = encoderSpec;
const PROPID propIDs[] =
const PROPID propIDs[] =
{
NCoderPropID::kAlgorithm,
NCoderPropID::kDictionarySize,
NCoderPropID::kDictionarySize,
NCoderPropID::kNumFastBytes,
};
const unsigned kNumProps = sizeof(propIDs) / sizeof(propIDs[0]);
@@ -185,16 +185,16 @@ const std::vector<unsigned char> LZMACompress(const std::vector<unsigned char>&
Error:
return std::vector<unsigned char> ();
}
COutStreamRam *const outStreamSpec = new COutStreamRam;
CMyComPtr<ISequentialOutStream> outStream = outStreamSpec;
CInStreamRam *const inStreamSpec = new CInStreamRam(buf);
CMyComPtr<ISequentialInStream> inStream = inStreamSpec;
outStreamSpec->Reserve(buf.size());
if (encoderSpec->WriteCoderProperties(outStream) != S_OK) goto Error;
for (unsigned i = 0; i < 8; i++)
{
UInt64 t = (UInt64)buf.size();
@@ -203,7 +203,7 @@ const std::vector<unsigned char> LZMACompress(const std::vector<unsigned char>&
HRESULT lzmaResult = encoder->Code(inStream, outStream, 0, 0, 0);
if (lzmaResult != S_OK) goto Error;
return outStreamSpec->Get();
}
@@ -216,22 +216,22 @@ const std::vector<unsigned char> LZMADeCompress
(const std::vector<unsigned char>& buf)
{
if(buf.size() <= 5+8) return std::vector<unsigned char> ();
uint_least64_t out_sizemax = R64(&buf[5]);
std::vector<unsigned char> result(out_sizemax);
CLzmaDecoderState state;
LzmaDecodeProperties(&state.Properties, &buf[0], LZMA_PROPERTIES_SIZE);
state.Probs = new CProb[LzmaGetNumProbs(&state.Properties)];
SizeT in_done;
SizeT out_done;
LzmaDecode(&state, &buf[13], buf.size()-13, &in_done,
&result[0], result.size(), &out_done);
delete[] state.Probs;
result.resize(out_done);
return result;
}
@@ -242,7 +242,7 @@ int main(int argc, char *argv[])
char *s;
FILE *f, *infile, *outfile;
int c;
if (argc != 4) {
std::fprintf(stderr, "'lzma e file1 file2' encodes file1 into file2.\n"
"'lzma d file2 file1' decodes file2 into file1.\n");
@@ -270,9 +270,9 @@ int main(int argc, char *argv[])
fread(Buf,si, 1, infile);
std::vector<unsigned char> result;
if (toupper(*argv[1]) == 'E')
if (toupper(*argv[1]) == 'E')
result = LZMACompress(std::vector<unsigned char>(Buf,Buf+si));
else
else
result = LZMADeCompress(std::vector<unsigned char>(Buf,Buf+si));
fwrite(&result[0], result.size(), 1, outfile);
@@ -289,7 +289,7 @@ extern "C" {
* @param in a pointer to the buffer
* @param in_len the length in bytes
* @param out a pointer to a buffer of at least size in_len
* @param out_len a pointer to the compressed length of in
* @param out_len a pointer to the compressed length of in
*/
void do_lzma_compress(char *in, int in_len, char *out, int *out_len) {
payloads/coreinfo/cpuid.S
+1 -1
View File
@@ -20,7 +20,7 @@
*/
/* calling syntax: docpuid(idx,eax,ebx,ecx,edx) */
.align 4
.text
payloads/coreinfo/pci_module.c
+1 -1
View File
@@ -194,7 +194,7 @@ static void pci_scan_bus(int bus)
if (devices_index >= MAX_PCI_DEVICES)
return;
devices[devices_index].device =
devices[devices_index].device =
PCI_DEV(bus, slot, func);
devices[devices_index++].id = val;
payloads/coreinfo/util/kconfig/lex.zconf.c_shipped
+43 -43
View File
@@ -52,7 +52,7 @@
#if __STDC_VERSION__ >= 199901L
/* C99 says to define __STDC_LIMIT_MACROS before including stdint.h,
* if you want the limit (max/min) macros for int types.
* if you want the limit (max/min) macros for int types.
*/
#ifndef __STDC_LIMIT_MACROS
#define __STDC_LIMIT_MACROS 1
@@ -69,7 +69,7 @@ typedef uint32_t flex_uint32_t;
typedef signed char flex_int8_t;
typedef short int flex_int16_t;
typedef int flex_int32_t;
typedef unsigned char flex_uint8_t;
typedef unsigned char flex_uint8_t;
typedef unsigned short int flex_uint16_t;
typedef unsigned int flex_uint32_t;
#endif /* ! C99 */
@@ -179,7 +179,7 @@ extern FILE *zconfin, *zconfout;
#define EOB_ACT_LAST_MATCH 2
#define YY_LESS_LINENO(n)
/* Return all but the first "n" matched characters back to the input stream. */
#define yyless(n) \
do \
@@ -246,7 +246,7 @@ struct yy_buffer_state
int yy_bs_lineno; /**< The line count. */
int yy_bs_column; /**< The column count. */
/* Whether to try to fill the input buffer when we reach the
* end of it.
*/
@@ -866,7 +866,7 @@ extern int zconfwrap (void );
#endif
static void yyunput (int c,char *buf_ptr );
#ifndef yytext_ptr
static void yy_flex_strncpy (char *,yyconst char *,int );
#endif
@@ -971,7 +971,7 @@ YY_DECL
register yy_state_type yy_current_state;
register char *yy_cp, *yy_bp;
register int yy_act;
int str = 0;
int ts, i;
@@ -1574,7 +1574,7 @@ static int yy_get_next_buffer (void)
{
register yy_state_type yy_current_state;
register char *yy_cp;
yy_current_state = (yy_start);
for ( yy_cp = (yytext_ptr) + YY_MORE_ADJ; yy_cp < (yy_c_buf_p); ++yy_cp )
@@ -1593,7 +1593,7 @@ static int yy_get_next_buffer (void)
static yy_state_type yy_try_NUL_trans (yy_state_type yy_current_state )
{
register int yy_is_jam;
yy_current_state = yy_nxt[yy_current_state][1];
yy_is_jam = (yy_current_state <= 0);
@@ -1603,7 +1603,7 @@ static int yy_get_next_buffer (void)
static void yyunput (int c, register char * yy_bp )
{
register char *yy_cp;
yy_cp = (yy_c_buf_p);
/* undo effects of setting up zconftext */
@@ -1646,7 +1646,7 @@ static int yy_get_next_buffer (void)
{
int c;
*(yy_c_buf_p) = (yy_hold_char);
if ( *(yy_c_buf_p) == YY_END_OF_BUFFER_CHAR )
@@ -1713,12 +1713,12 @@ static int yy_get_next_buffer (void)
/** Immediately switch to a different input stream.
* @param input_file A readable stream.
*
*
* @note This function does not reset the start condition to @c INITIAL .
*/
void zconfrestart (FILE * input_file )
{
if ( ! YY_CURRENT_BUFFER ){
zconfensure_buffer_stack ();
YY_CURRENT_BUFFER_LVALUE =
@@ -1731,11 +1731,11 @@ static int yy_get_next_buffer (void)
/** Switch to a different input buffer.
* @param new_buffer The new input buffer.
*
*
*/
void zconf_switch_to_buffer (YY_BUFFER_STATE new_buffer )
{
/* TODO. We should be able to replace this entire function body
* with
* zconfpop_buffer_state();
@@ -1775,13 +1775,13 @@ static void zconf_load_buffer_state (void)
/** Allocate and initialize an input buffer state.
* @param file A readable stream.
* @param size The character buffer size in bytes. When in doubt, use @c YY_BUF_SIZE.
*
*
* @return the allocated buffer state.
*/
YY_BUFFER_STATE zconf_create_buffer (FILE * file, int size )
{
YY_BUFFER_STATE b;
b = (YY_BUFFER_STATE) zconfalloc(sizeof( struct yy_buffer_state ) );
if ( ! b )
YY_FATAL_ERROR( "out of dynamic memory in zconf_create_buffer()" );
@@ -1804,11 +1804,11 @@ static void zconf_load_buffer_state (void)
/** Destroy the buffer.
* @param b a buffer created with zconf_create_buffer()
*
*
*/
void zconf_delete_buffer (YY_BUFFER_STATE b )
{
if ( ! b )
return;
@@ -1829,7 +1829,7 @@ static void zconf_load_buffer_state (void)
{
int oerrno = errno;
zconf_flush_buffer(b );
b->yy_input_file = file;
@@ -1845,13 +1845,13 @@ static void zconf_load_buffer_state (void)
}
b->yy_is_interactive = 0;
errno = oerrno;
}
/** Discard all buffered characters. On the next scan, YY_INPUT will be called.
* @param b the buffer state to be flushed, usually @c YY_CURRENT_BUFFER.
*
*
*/
void zconf_flush_buffer (YY_BUFFER_STATE b )
{
@@ -1880,7 +1880,7 @@ static void zconf_load_buffer_state (void)
* the current state. This function will allocate the stack
* if necessary.
* @param new_buffer The new state.
*
*
*/
void zconfpush_buffer_state (YY_BUFFER_STATE new_buffer )
{
@@ -1910,7 +1910,7 @@ void zconfpush_buffer_state (YY_BUFFER_STATE new_buffer )
/** Removes and deletes the top of the stack, if present.
* The next element becomes the new top.
*
*
*/
void zconfpop_buffer_state (void)
{
@@ -1934,7 +1934,7 @@ void zconfpop_buffer_state (void)
static void zconfensure_buffer_stack (void)
{
int num_to_alloc;
if (!(yy_buffer_stack)) {
/* First allocation is just for 2 elements, since we don't know if this
@@ -1945,9 +1945,9 @@ static void zconfensure_buffer_stack (void)
(yy_buffer_stack) = (struct yy_buffer_state**)zconfalloc
(num_to_alloc * sizeof(struct yy_buffer_state*)
);
memset((yy_buffer_stack), 0, num_to_alloc * sizeof(struct yy_buffer_state*));
(yy_buffer_stack_max) = num_to_alloc;
(yy_buffer_stack_top) = 0;
return;
@@ -1973,13 +1973,13 @@ static void zconfensure_buffer_stack (void)
/** Setup the input buffer state to scan directly from a user-specified character buffer.
* @param base the character buffer
* @param size the size in bytes of the character buffer
*
* @return the newly allocated buffer state object.
*
* @return the newly allocated buffer state object.
*/
YY_BUFFER_STATE zconf_scan_buffer (char * base, yy_size_t size )
{
YY_BUFFER_STATE b;
if ( size < 2 ||
base[size-2] != YY_END_OF_BUFFER_CHAR ||
base[size-1] != YY_END_OF_BUFFER_CHAR )
@@ -2008,14 +2008,14 @@ YY_BUFFER_STATE zconf_scan_buffer (char * base, yy_size_t size )
/** Setup the input buffer state to scan a string. The next call to zconflex() will
* scan from a @e copy of @a str.
* @param str a NUL-terminated string to scan
*
*
* @return the newly allocated buffer state object.
* @note If you want to scan bytes that may contain NUL values, then use
* zconf_scan_bytes() instead.
*/
YY_BUFFER_STATE zconf_scan_string (yyconst char * yystr )
{
return zconf_scan_bytes(yystr,strlen(yystr) );
}
@@ -2023,7 +2023,7 @@ YY_BUFFER_STATE zconf_scan_string (yyconst char * yystr )
* scan from a @e copy of @a bytes.
* @param bytes the byte buffer to scan
* @param len the number of bytes in the buffer pointed to by @a bytes.
*
*
* @return the newly allocated buffer state object.
*/
YY_BUFFER_STATE zconf_scan_bytes (yyconst char * yybytes, int _yybytes_len )
@@ -2032,7 +2032,7 @@ YY_BUFFER_STATE zconf_scan_bytes (yyconst char * yybytes, int _yybytes_len )
char *buf;
yy_size_t n;
int i;
/* Get memory for full buffer, including space for trailing EOB's. */
n = _yybytes_len + 2;
buf = (char *) zconfalloc(n );
@@ -2086,16 +2086,16 @@ static void yy_fatal_error (yyconst char* msg )
/* Accessor methods (get/set functions) to struct members. */
/** Get the current line number.
*
*
*/
int zconfget_lineno (void)
{
return zconflineno;
}
/** Get the input stream.
*
*
*/
FILE *zconfget_in (void)
{
@@ -2103,7 +2103,7 @@ FILE *zconfget_in (void)
}
/** Get the output stream.
*
*
*/
FILE *zconfget_out (void)
{
@@ -2111,7 +2111,7 @@ FILE *zconfget_out (void)
}
/** Get the length of the current token.
*
*
*/
int zconfget_leng (void)
{
@@ -2119,7 +2119,7 @@ int zconfget_leng (void)
}
/** Get the current token.
*
*
*/
char *zconfget_text (void)
@@ -2129,18 +2129,18 @@ char *zconfget_text (void)
/** Set the current line number.
* @param line_number
*
*
*/
void zconfset_lineno (int line_number )
{
zconflineno = line_number;
}
/** Set the input stream. This does not discard the current
* input buffer.
* @param in_str A readable stream.
*
*
* @see zconf_switch_to_buffer
*/
void zconfset_in (FILE * in_str )
@@ -2194,7 +2194,7 @@ static int yy_init_globals (void)
/* zconflex_destroy is for both reentrant and non-reentrant scanners. */
int zconflex_destroy (void)
{
/* Pop the buffer stack, destroying each element. */
while(YY_CURRENT_BUFFER){
zconf_delete_buffer(YY_CURRENT_BUFFER );
payloads/coreinfo/util/kconfig/lxdialog/BIG.FAT.WARNING
+1 -1
View File
@@ -1,4 +1,4 @@
This is NOT the official version of dialog. This version has been
significantly modified from the original. It is for use by the Linux
kernel configuration script. Please do not bother Savio Lam with
kernel configuration script. Please do not bother Savio Lam with
questions about this program.
payloads/coreinfo/util/kconfig/lxdialog/menubox.c
+1 -1
View File
@@ -26,7 +26,7 @@
*
* *) A bugfix for the Page-Down problem
*
* *) Formerly when I used Page Down and Page Up, the cursor would be set
* *) Formerly when I used Page Down and Page Up, the cursor would be set
* to the first position in the menu box. Now lxdialog is a bit
* smarter and works more like other menu systems (just have a look at
* it).

Some files were not shown because too many files have changed in this diff Show More