<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/Makefile, branch v2016.09</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>drivers/sysreset: group sysreset drivers</title>
<updated>2016-08-12T13:22:17+00:00</updated>
<author>
<name>Max Filippov</name>
<email>jcmvbkbc@gmail.com</email>
</author>
<published>2016-08-07T05:53:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b25732c22beccb5a2ce3ec4174ea084ba0e176ab'/>
<id>b25732c22beccb5a2ce3ec4174ea084ba0e176ab</id>
<content type='text'>
Create drivers/sysreset and move sysreset-uclass and all sysreset
drivers there.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Create drivers/sysreset and move sysreset-uclass and all sysreset
drivers there.

Signed-off-by: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spl: Lightweight UBI and UBI fastmap support</title>
<updated>2016-07-22T13:53:00+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2016-07-12T18:28:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6f4e7d3c75a81decc20de0218729e9770448ffc0'/>
<id>6f4e7d3c75a81decc20de0218729e9770448ffc0</id>
<content type='text'>
Booting a payload out of NAND FLASH from the SPL is a crux today, as
it requires hard partioned FLASH. Not a brilliant idea with the
reliability of todays NAND FLASH chips.

The upstream UBI + UBI fastmap implementation which is about to
brought to u-boot is too heavy weight for SPLs as it provides way more
functionality than needed for a SPL and does not even fit into the
restricted SPL areas which are loaded from the SoC boot ROM.

So this provides a fast and lightweight implementation of UBI scanning
and UBI fastmap attach. The scan and logical to physical block mapping
code is developed from scratch, while the fastmap implementation is
lifted from the linux kernel source and stripped down to fit the SPL
needs.

The text foot print on the board which I used for development is:

6854	0	0	6854	1abd
drivers/mtd/ubispl/built-in.o

Attaching a NAND chip with 4096 physical eraseblocks (4 blocks are
reserved for the SPL) takes:

In full scan mode:      1172ms
In fastmap mode:          95ms

The code requires quite some storage. The largest and unknown part of
it is the number of fastmap blocks to read. Therefor the data
structure is not put into the BSS. The code requires a pointer to free
memory handed in which is initialized by the UBI attach code itself.

See doc/README.ubispl for further information on how to use it.

This shares the ubi-media.h and crc32 implementation of drivers/mtd/ubi
There is no way to share the fastmap code, as UBISPL only utilizes the
slightly modified functions ubi_attach_fastmap() and ubi_scan_fastmap()
from the original kernel ubi fastmap implementation.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Acked-by: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Booting a payload out of NAND FLASH from the SPL is a crux today, as
it requires hard partioned FLASH. Not a brilliant idea with the
reliability of todays NAND FLASH chips.

The upstream UBI + UBI fastmap implementation which is about to
brought to u-boot is too heavy weight for SPLs as it provides way more
functionality than needed for a SPL and does not even fit into the
restricted SPL areas which are loaded from the SoC boot ROM.

So this provides a fast and lightweight implementation of UBI scanning
and UBI fastmap attach. The scan and logical to physical block mapping
code is developed from scratch, while the fastmap implementation is
lifted from the linux kernel source and stripped down to fit the SPL
needs.

The text foot print on the board which I used for development is:

6854	0	0	6854	1abd
drivers/mtd/ubispl/built-in.o

Attaching a NAND chip with 4096 physical eraseblocks (4 blocks are
reserved for the SPL) takes:

In full scan mode:      1172ms
In fastmap mode:          95ms

The code requires quite some storage. The largest and unknown part of
it is the number of fastmap blocks to read. Therefor the data
structure is not put into the BSS. The code requires a pointer to free
memory handed in which is initialized by the UBI attach code itself.

See doc/README.ubispl for further information on how to use it.

This shares the ubi-media.h and crc32 implementation of drivers/mtd/ubi
There is no way to share the fastmap code, as UBISPL only utilizes the
slightly modified functions ubi_attach_fastmap() and ubi_scan_fastmap()
from the original kernel ubi fastmap implementation.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Acked-by: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: Sort subsystem directories aplhabeticaly in Makefile</title>
<updated>2016-07-22T13:52:59+00:00</updated>
<author>
<name>Ladislav Michl</name>
<email>ladis@linux-mips.org</email>
</author>
<published>2016-07-12T18:28:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=05fc5ef161779ed1b0b479e8d085026d6994731a'/>
<id>05fc5ef161779ed1b0b479e8d085026d6994731a</id>
<content type='text'>
Signed-off-by: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add a reset driver framework/uclass</title>
<updated>2016-06-19T23:05:55+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2016-06-17T15:43:58+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=89c1e2da78f82a09685006291ce8bb44f635fa25'/>
<id>89c1e2da78f82a09685006291ce8bb44f635fa25</id>
<content type='text'>
A reset controller is a hardware module that controls reset signals that
affect other hardware modules or chips.

This patch defines a standard API that connects reset clients (i.e. the
drivers for devices affected by reset signals) to drivers for reset
controllers/providers. Initially, DT is the only supported method for
connecting the two.

The DT binding specification (reset.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/reset/reset.txt.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A reset controller is a hardware module that controls reset signals that
affect other hardware modules or chips.

This patch defines a standard API that connects reset clients (i.e. the
drivers for devices affected by reset signals) to drivers for reset
controllers/providers. Initially, DT is the only supported method for
connecting the two.

The DT binding specification (reset.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/reset/reset.txt.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>verified-boot: Minimal support for booting U-Boot proper from SPL</title>
<updated>2016-06-12T17:14:58+00:00</updated>
<author>
<name>Teddy Reed</name>
<email>teddy.reed@gmail.com</email>
</author>
<published>2016-06-10T02:18:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=51c14cd128f4355514397dc3c8647fb14f7d8ff4'/>
<id>51c14cd128f4355514397dc3c8647fb14f7d8ff4</id>
<content type='text'>
This allows a board to configure verified boot within the SPL using
a FIT or FIT with external data. It also allows the SPL to perform
signature verification without needing relocation.

The board configuration will need to add the following feature defines:
CONFIG_SPL_CRYPTO_SUPPORT
CONFIG_SPL_HASH_SUPPORT
CONFIG_SPL_SHA256

In this example, SHA256 is the only selected hashing algorithm.

And the following booleans:
CONFIG_SPL=y
CONFIG_SPL_DM=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_SPL_OF_LIBFDT=y
CONFIG_SPL_FIT_SIGNATURE=y

Signed-off-by: Teddy Reed &lt;teddy.reed@gmail.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
Acked-by: Andreas Dannenberg &lt;dannenberg@ti.com&gt;
Acked-by: Sumit Garg &lt;sumit.garg@nxp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows a board to configure verified boot within the SPL using
a FIT or FIT with external data. It also allows the SPL to perform
signature verification without needing relocation.

The board configuration will need to add the following feature defines:
CONFIG_SPL_CRYPTO_SUPPORT
CONFIG_SPL_HASH_SUPPORT
CONFIG_SPL_SHA256

In this example, SHA256 is the only selected hashing algorithm.

And the following booleans:
CONFIG_SPL=y
CONFIG_SPL_DM=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_SPL_OF_LIBFDT=y
CONFIG_SPL_FIT_SIGNATURE=y

Signed-off-by: Teddy Reed &lt;teddy.reed@gmail.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
Acked-by: Andreas Dannenberg &lt;dannenberg@ti.com&gt;
Acked-by: Sumit Garg &lt;sumit.garg@nxp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add a mailbox driver framework/uclass</title>
<updated>2016-05-27T02:48:31+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2016-05-13T21:50:29+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6238935d018042d332aa7e90eae3addfeb11abdc'/>
<id>6238935d018042d332aa7e90eae3addfeb11abdc</id>
<content type='text'>
A mailbox is a hardware mechanism for transferring small message and/or
notifications between the CPU on which U-Boot runs and some other device
such as an auxilliary CPU running firmware or a hardware module.

This patch defines a standard API that connects mailbox clients to mailbox
providers (drivers). Initially, DT is the only supported method for
connecting the two.

The DT binding specification (mailbox.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A mailbox is a hardware mechanism for transferring small message and/or
notifications between the CPU on which U-Boot runs and some other device
such as an auxilliary CPU running firmware or a hardware module.

This patch defines a standard API that connects mailbox clients to mailbox
providers (drivers). Initially, DT is the only supported method for
connecting the two.

The DT binding specification (mailbox.txt) was taken from Linux kernel
v4.5's Documentation/devicetree/bindings/mailbox/mailbox.txt.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Acked-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dm: mmc: spl: Use the legacy block interface in SPL</title>
<updated>2016-05-17T15:54:43+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2016-05-01T19:52:28+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0776167ec5541a2b4fa099dfea5a1aad2d4b7c72'/>
<id>0776167ec5541a2b4fa099dfea5a1aad2d4b7c72</id>
<content type='text'>
Bring this in for SPL so that we can use generic code for loading from
block devices.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Bring this in for SPL so that we can use generic code for loading from
block devices.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dm: usb: Drop the get_dev() function</title>
<updated>2016-05-17T15:54:43+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2016-05-01T17:36:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=57ebf67bad82da0b3ade1728fb39a64d1c29822f'/>
<id>57ebf67bad82da0b3ade1728fb39a64d1c29822f</id>
<content type='text'>
This function is implemented by the legacy block functions now. Drop it.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This function is implemented by the legacy block functions now. Drop it.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: Add SPMI bus uclass</title>
<updated>2016-04-01T21:18:12+00:00</updated>
<author>
<name>Mateusz Kulikowski</name>
<email>mateusz.kulikowski@gmail.com</email>
</author>
<published>2016-03-31T21:12:27+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=04868b407b624c414805c9e9a79195eeb3a14829'/>
<id>04868b407b624c414805c9e9a79195eeb3a14829</id>
<content type='text'>
Qualcom processors use proprietary bus to talk with PMIC devices -
SPMI (System Power Management Interface).
On wiring level it is similar to I2C, but on protocol level, it's
multi-master and has simple autodetection capabilities.
This commit adds simple uclass that provides bus read/write interface.

Signed-off-by: Mateusz Kulikowski &lt;mateusz.kulikowski@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Qualcom processors use proprietary bus to talk with PMIC devices -
SPMI (System Power Management Interface).
On wiring level it is similar to I2C, but on protocol level, it's
multi-master and has simple autodetection capabilities.
This commit adds simple uclass that provides bus read/write interface.

Signed-off-by: Mateusz Kulikowski &lt;mateusz.kulikowski@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Tested-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: ddr: Add DDR2 SDRAM controller driver for Microchip PIC32.</title>
<updated>2016-02-01T21:14:01+00:00</updated>
<author>
<name>Purna Chandra Mandal</name>
<email>purna.mandal@microchip.com</email>
</author>
<published>2016-01-28T10:00:15+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9ffa7a35ef940b27813c11f68eb28a6b82696915'/>
<id>9ffa7a35ef940b27813c11f68eb28a6b82696915</id>
<content type='text'>
This driver initializes PIC32 DDR2 SDRAM controller and internal DDR2 Phy module.
DDR2 controller operates in half-rate mode (upto 533MHZ frequency).

Signed-off-by: Paul Thacker &lt;paul.thacker@microchip.com&gt;
Signed-off-by: Purna Chandra Mandal &lt;purna.mandal@microchip.com&gt;
Reviewed-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver initializes PIC32 DDR2 SDRAM controller and internal DDR2 Phy module.
DDR2 controller operates in half-rate mode (upto 533MHZ frequency).

Signed-off-by: Paul Thacker &lt;paul.thacker@microchip.com&gt;
Signed-off-by: Purna Chandra Mandal &lt;purna.mandal@microchip.com&gt;
Reviewed-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
