<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/x86/lib, branch v2017.07</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/arch/x86/lib?h=v2017.07</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/arch/x86/lib?h=v2017.07'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2017-06-05T00:55:22Z</updated>
<entry>
<title>x86: fsp: Remove the call to set up internal uart in fsp_init()</title>
<updated>2017-06-05T00:55:22Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-06-01T10:41:14Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d7f7ba36b2edecb16393f8373cca833adb8ea6c3'/>
<id>urn:sha1:d7f7ba36b2edecb16393f8373cca833adb8ea6c3</id>
<content type='text'>
First of all, it's inappropriate to call setup_internal_uart() in a
generic API fsp_init(), as CONFIG_INTERNAL_UART is an option that
is only available on BayTrail platform. Secondly even for BayTrail,
there is no need to call setup_internal_uart() at all, as Intel FSP
will do this for us.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>x86: bootm: Add dm_remove_devices_flags() call to bootm_announce_and_cleanup()</title>
<updated>2017-05-17T09:13:06Z</updated>
<author>
<name>Stefan Roese</name>
<email>sr@denx.de</email>
</author>
<published>2017-04-24T07:48:03Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7025b05415ff97824266ce59b7f7915032ba6403'/>
<id>urn:sha1:7025b05415ff97824266ce59b7f7915032ba6403</id>
<content type='text'>
This patch adds a call to dm_remove_devices_flags() to
bootm_announce_and_cleanup() so that drivers that have one of the removal
flags set (e.g. DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may
do some last-stage cleanup before the OS is started.

Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
Cc: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>x86: acpi: Fix Windows S3 resume failure</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:47Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5ae5aa931042bb4163c6343a3cba65e95d90205a'/>
<id>urn:sha1:5ae5aa931042bb4163c6343a3cba65e95d90205a</id>
<content type='text'>
U-Boot sets up the real mode interrupt handler stubs starting from
address 0x1000. In most cases, the first 640K (0x00000 - 0x9ffff)
system memory is reported as system RAM in E820 table to the OS.
(see install_e820_map() implementation for each platform). So OS
can use these memories whatever it wants.

If U-Boot is in an S3 resume path, care must be taken not to corrupt
these memorie otherwise OS data gets lost. Testing shows that, on
Microsoft Windows 10 on Intel Baytrail its wake up vector happens to
be installed at the same address 0x1000. While on Linux its wake up
vector does not overlap this memory range, but after resume kernel
checks low memory range per config option CONFIG_X86_RESERVE_LOW
which is 64K by default to see whether a memory corruption occurs
during the suspend/resume (it's harmless, but warnings are shown
in the kernel dmesg logs).

We cannot simply mark the these memory as reserved in E820 table
because such configuration makes GRUB complain: unable to allocate
real mode page. Hence we choose to back up these memories to the
place where we reserved on our stack for our S3 resume work.
Before jumping to OS wake up vector, we need restore the original
content there.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>x86: acpi: Turn on ACPI mode for S3</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:45Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=82a5648f5604709ae405b7faf23e68dc700b58d9'/>
<id>urn:sha1:82a5648f5604709ae405b7faf23e68dc700b58d9</id>
<content type='text'>
Before jumping to OS waking up vector, we need turn on ACPI mode
for S3, just like what we do for a normal boot.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>x86: acpi: Refactor acpi_resume()</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:44Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0f4e25887dfb3b54b21430340c511f7fd54bc955'/>
<id>urn:sha1:0f4e25887dfb3b54b21430340c511f7fd54bc955</id>
<content type='text'>
To do something more in acpi_resume() like turning on ACPI mode,
we need locate ACPI FADT table pointer first. But currently this
is done in acpi_find_wakeup_vector().

This changes acpi_resume() signature to accept ACPI FADT pointer
as the parameter. A new API acpi_find_fadt() is introduced, and
acpi_find_wakeup_vector() is updated to use FADT pointer as the
parameter as well.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>x86: acpi: Make enter_acpi_mode() public</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:43Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=995727850f8e54547bb26285ef9e2aa73a5c71a5'/>
<id>urn:sha1:995727850f8e54547bb26285ef9e2aa73a5c71a5</id>
<content type='text'>
enter_acpi_mode() is useful on other boot path like S3 resume, so
make it public.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>x86: apci: Change PM1_CNT register access to RMW</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:42Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b208d1915f1bdba93678b51b87ae214d9e2ca7a3'/>
<id>urn:sha1:b208d1915f1bdba93678b51b87ae214d9e2ca7a3</id>
<content type='text'>
In enter_acpi_mode() PM1_CNT register is changed to PM1_CNT_SCI_EN
directly without preserving its previous value. Update to change
the register access to read-modify-write (RMW).

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>x86: Do not clear high table area for S3</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:40Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=95e50dd197cb86641a4ad06a18d5a4c57ea0a6f4'/>
<id>urn:sha1:95e50dd197cb86641a4ad06a18d5a4c57ea0a6f4</id>
<content type='text'>
When SeaBIOS is being used, U-Boot reserves a memory area to be
used for configuration tables like ACPI. But it should not be
cleared otherwise ACPI table will be missing.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>x86: fsp: Save stack address to CMOS for next S3 boot</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:39Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ba65808e7d0699e053c9892983312a11d4e2a30a'/>
<id>urn:sha1:ba65808e7d0699e053c9892983312a11d4e2a30a</id>
<content type='text'>
At the end of pre-relocation phase, save the new stack address
to CMOS and use it as the stack on next S3 boot for fsp_init()
continuation function.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>x86: Add an early CMOS access library</title>
<updated>2017-05-17T09:11:46Z</updated>
<author>
<name>Bin Meng</name>
<email>bmeng.cn@gmail.com</email>
</author>
<published>2017-04-21T14:24:38Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9f1fad1e365f413e4f6f5a608a70be0e6ba95dc8'/>
<id>urn:sha1:9f1fad1e365f413e4f6f5a608a70be0e6ba95dc8</id>
<content type='text'>
This adds a library that provides CMOS (inside RTC SRAM) access
at a very early stage when driver model is not available yet.

Signed-off-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
</feed>
