u-boot.git/tools/ifdtool.c, branch v2016.07 Unnamed repository; edit this file 'description' to name the repository. x86: ifdtool: Support checking region overlap before U-Boot 2015-09-09T13:48:03+00:00 Bin Meng bmeng.cn@gmail.com 2015-08-27T15:38:15+00:00 e6378e1da2eafb2facef8e0fe904ac1194d4fd62 We have the capability to check regions written after U-Boot that do not overlap. Since regions can also be written before U-Boot, add such check for these too. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Andy Pont <andy.pont@sdcsystems.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> 
We have the capability to check regions written after U-Boot that
do not overlap. Since regions can also be written before U-Boot,
add such check for these too.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Andy Pont <andy.pont@sdcsystems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
x86: ifdtool: Drop microcode from the device tree when collating 2015-08-26T14:54:10+00:00 Simon Glass sjg@chromium.org 2015-08-15T20:37:54+00:00 f86f0c1897436e03b0e68874a56b257080d01386 When ifdtool collates the microcode into one place it effectively creates a copy of the 'data' properties in the device tree microcode nodes. This is wasteful since we now have two copies of the microcode in the ROM. To avoid this, remove the microcode data from the device tree and shrink it down. This means that there is only one copy and the overall ROM space used by the microcode does not increase. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> 
When ifdtool collates the microcode into one place it effectively creates
a copy of the 'data' properties in the device tree microcode nodes. This
is wasteful since we now have two copies of the microcode in the ROM.

To avoid this, remove the microcode data from the device tree and shrink it
down. This means that there is only one copy and the overall ROM space used
by the microcode does not increase.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
x86: ifdtool: Support collating microcode into one place 2015-08-26T14:54:10+00:00 Simon Glass sjg@chromium.org 2015-08-15T20:37:53+00:00 b098032387a6ba1cab181a897075932f7fa2a58d The Intel Firmware Support Package (FSP) requires that microcode be provided very early before the device tree can be scanned. We already support adding a pointer to the microcode data in a place where early init code can access. However this just points into the device tree and can only point to a single lot of microcode. For boards which may have different CPU types we must support multiple microcodes and pass all of them to the FSP in one place. Enhance ifdtool to scan all the microcode, place it together in the ROM and update the microcode pointer to point there. This allows us to pass multiple microcode blocks to the FSP using its existing API. Enable the flag in the Makefile so that this feature is used by default for all boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> 
The Intel Firmware Support Package (FSP) requires that microcode be provided
very early before the device tree can be scanned. We already support adding
a pointer to the microcode data in a place where early init code can access.

However this just points into the device tree and can only point to a single
lot of microcode. For boards which may have different CPU types we must
support multiple microcodes and pass all of them to the FSP in one place.

Enhance ifdtool to scan all the microcode, place it together in the ROM and
update the microcode pointer to point there. This allows us to pass multiple
microcode blocks to the FSP using its existing API.

Enable the flag in the Makefile so that this feature is used by default for
all boards.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
x86: ifdtool: Split microcode linking into its own function 2015-08-26T14:54:10+00:00 Simon Glass sjg@chromium.org 2015-08-15T20:37:52+00:00 88cf322e44b85a0e17ce5a5514eff85e7df78dc6 The code to set up the microcode pointer in the ROM shares almost nothing with the write_uboot() function. Move it into its own function so it will be easier to extend. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> 
The code to set up the microcode pointer in the ROM shares almost nothing
with the write_uboot() function.

Move it into its own function so it will be easier to extend.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
x86: ifdtool: Check that U-Boot does not overlap other regions 2015-08-26T14:54:10+00:00 Simon Glass sjg@chromium.org 2015-08-15T20:37:51+00:00 3c7aab23a42264012d82937dd2a57e33ee288a92 Since U-Boot and its device tree can grow we should check that it does not overlap the regions above it. Track the ROM offset that U-Boot reaches and check that other regions (written after U-Boot) do not interfere. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> 
Since U-Boot and its device tree can grow we should check that it does not
overlap the regions above it. Track the ROM offset that U-Boot reaches and
check that other regions (written after U-Boot) do not interfere.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
tools: ifdtool: Write correct offset on 32-bit machine 2015-07-15T00:03:19+00:00 Bin Meng bmeng.cn@gmail.com 2015-07-06T07:57:06+00:00 50e8a6bba0cf5939afe849ef792f88f09a755758 On 32-bit machine strtol() returns LONG_MAX which is 0x7fffffff, which is wrong for u-boot.rom components like u-boot-x86-16bit.bin. Change to use strtoll() so that it works on both 32-bit and 64-bit machines. Reported-by: Fei Wang <wangfei.jimei@gmail.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> 
On 32-bit machine strtol() returns LONG_MAX which is 0x7fffffff,
which is wrong for u-boot.rom components like u-boot-x86-16bit.bin.
Change to use strtoll() so that it works on both 32-bit and 64-bit
machines.

Reported-by: Fei Wang <wangfei.jimei@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
tools: ifdtool: Do not write region while its size is negative 2015-06-04T09:02:57+00:00 Bin Meng bmeng.cn@gmail.com 2015-05-31T06:57:35+00:00 6c4247e98eb3b1bf7ec19b61915c803db5670ad0 We should ignore those regions whose size is negative. These are typically optional and unused regions (like GbE and platform data). Change-Id: I65ad01746144604a1dc0588b617af21f2722ebbf Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> 
We should ignore those regions whose size is negative. These are
typically optional and unused regions (like GbE and platform data).

Change-Id: I65ad01746144604a1dc0588b617af21f2722ebbf
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
x86: Correct ifdtool microcode calculation 2015-01-13T15:24:58+00:00 Simon Glass sjg@chromium.org 2015-01-01T23:17:56+00:00 8a388085c70d0da306cbd0dc644606cf8be24486 This currently assumes that U-Boot resides at the start of ROM. Update it to remove this assumption. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com> 
This currently assumes that U-Boot resides at the start of ROM. Update
it to remove this assumption.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
x86: ifdtool: Add support for early microcode access 2014-12-19T00:26:05+00:00 Simon Glass sjg@chromium.org 2014-12-16T05:02:38+00:00 31eca697276ef9aced10b802a869e7783439482e Some Intel CPUs use an 'FSP' binary blob which provides an inflexible means of starting up the CPU. One result is that microcode updates can only be done before RAM is available and therefore parsing of the device tree is impracticle. Worse, the addess of the microcode update must be stored in ROM since a pointer to its start address and size is passed to the 'FSP' blob. It is not possible to perform any calculations to obtain the address and size. To work around this, ifdtool is enhanced to work out the address and size of the first microcode update it finds in the supplied device tree. It then writes these into the correct place in the ROM. U-Boot can then start up the FSP correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
Some Intel CPUs use an 'FSP' binary blob which provides an inflexible
means of starting up the CPU. One result is that microcode updates can only
be done before RAM is available and therefore parsing of the device tree
is impracticle.

Worse, the addess of the microcode update must be stored in ROM since a
pointer to its start address and size is passed to the 'FSP' blob. It is
not possible to perform any calculations to obtain the address and size.

To work around this, ifdtool is enhanced to work out the address and size of
the first microcode update it finds in the supplied device tree. It then
writes these into the correct place in the ROM. U-Boot can then start up
the FSP correctly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
x86: ifdtool: Use a structure for the file/address list 2014-12-19T00:26:04+00:00 Simon Glass sjg@chromium.org 2014-12-15T00:15:37+00:00 65851fcec305bae079b35e17103aa61c8ef54674 Rather than two independent arrays, use a single array of a suitable structure. Also add a 'type' member since we will shortly add additional types. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
Rather than two independent arrays, use a single array of a suitable
structure. Also add a 'type' member since we will shortly add additional
types.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>