u-boot.git/doc, branch v2023.01 Unnamed repository; edit this file 'description' to name the repository. Prepare v2023.01 2023-01-09T16:07:33+00:00 Tom Rini trini@konsulko.com 2023-01-09T16:07:33+00:00 62e2ad1ceafbfdf2c44d3dc1b6efc81e768a96b9 Signed-off-by: Tom Rini <trini@konsulko.com> 
Signed-off-by: Tom Rini <trini@konsulko.com>
doc: building documentation 2023-01-04T12:17:42+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2022-12-30T04:05:31+00:00 566b7b2f518797540413bf55862b6562158aced9 Provide a man-page describing how to build the U-Boot documentation. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Provide a man-page describing how to build the U-Boot documentation.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: improve wget man-page 2022-12-29T09:51:50+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2022-12-22T10:32:03+00:00 159dbe1fb12b20580f76f69173b176244d91b796 * correct formatting of synopsis * improve description of TCP SACK configuration Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
* correct formatting of synopsis
* improve description of TCP SACK configuration

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: Use "changesets" not "csets" in statistics pages 2022-12-29T09:51:50+00:00 Tom Rini trini@konsulko.com 2022-12-21T23:04:10+00:00 f16086e3e2c1158bdb4f95c572567b13634a8669 To make things more human readable, say "changesets from" rather than "csets from" in all our historical pages here. Moving forward this has been changed in our gitdm with b034e399e31a ("gitdm: fix typo csets"). Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
To make things more human readable, say "changesets from" rather than
"csets from" in all our historical pages here. Moving forward this has
been changed in our gitdm with b034e399e31a ("gitdm: fix typo csets").

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: add texinfodocs and infodocs targets 2022-12-29T09:51:50+00:00 Maxim Cournoyer maxim.cournoyer@gmail.com 2022-12-19T02:48:08+00:00 7fa4c27a2e1131702ae7f665c3572cdd4ead27b3 Sphinx supports generating Texinfo sources and Info documentation, which can be navigated easily and is convenient to search (via the indexed nodes or anchors, for example). This is basically the same as 1f050e904dd6f2955eecbd22031d912ccb2e7683, which was recently applied to the Linux kernel. Signed-off-by: Maxim Cournoyer <maxim.cournoyer@savoirfairelinux.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Sphinx supports generating Texinfo sources and Info documentation,
which can be navigated easily and is convenient to search (via the
indexed nodes or anchors, for example).  This is basically the same as
1f050e904dd6f2955eecbd22031d912ccb2e7683, which was recently applied
to the Linux kernel.

Signed-off-by: Maxim Cournoyer <maxim.cournoyer@savoirfairelinux.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: board: qemu-ppce500: Update supported and unsupported 2022-12-29T09:51:50+00:00 Pali Rohár pali@kernel.org 2022-12-20T20:06:26+00:00 a17be96b62476ccdb4838742f31e227963a69d65 qemu can emulate also e500v1 core but cannot emulate CPUs from Freescale PowerPC QorIQ T and P series. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
qemu can emulate also e500v1 core but cannot emulate CPUs from Freescale
PowerPC QorIQ T and P series.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: ti: add the K3 generation page 2022-12-29T09:51:50+00:00 Bryan Brattlof bb@ti.com 2022-12-19T20:29:50+00:00 16a30b3474a3813465b6b6d1b280fc7dc9a9f7ba Texas Instrument's entire K3 generation of SoCs use much of the same frameworks and boot flow, especially at the uboot level. Though there are small differences introduced as each new K3 based SoC is developed and as the K3 generation matures that will also need to be documented. Rather than copying the same documentation, with the small differences applicable to that specific SoC to a new page, introduce a new K3 page that can describe the general boot flow and design decisions for the entire K3 generation of chips, leaving the specifics for that particular SoC to a unique sub-page below this one. Signed-off-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Texas Instrument's entire K3 generation of SoCs use much of the same
frameworks and boot flow, especially at the uboot level. Though there
are small differences introduced as each new K3 based SoC is developed
and as the K3 generation matures that will also need to be documented.

Rather than copying the same documentation, with the small differences
applicable to that specific SoC to a new page, introduce a new K3
page that can describe the general boot flow and design decisions for
the entire K3 generation of chips, leaving the specifics for that
particular SoC to a unique sub-page below this one.

Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: ti: reorganize existing ti docs 2022-12-29T09:51:50+00:00 Bryan Brattlof bb@ti.com 2022-12-19T20:29:49+00:00 0820e117c3a20afbf0ec611475e3719e8d8c83b1 Texas Instruments produces quite a lot of SoCs based upon a common architecture 'generation'. (eg: OMAP, K3) TI's existing documentation layout makes noticing this generation jump rather difficult. To make navigation easier, split the existing documentation into individual SoC families so we may begin grouping them according to their generational (eg: OMAP, K3) families. Signed-off-by: Bryan Brattlof <bb@ti.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Texas Instruments produces quite a lot of SoCs based upon a common
architecture 'generation'. (eg: OMAP, K3) TI's existing documentation
layout makes noticing this generation jump rather difficult.

To make navigation easier, split the existing documentation into
individual SoC families so we may begin grouping them according to their
generational (eg: OMAP, K3) families.

Signed-off-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
doc: correct heading level in printenv man-page 2022-12-20T15:06:48+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2022-12-18T04:00:52+00:00 f9178e19a1fe8d1bde897af4265bae2d889648db The 'Configuration' heading should be on level 2, not on level 1. Fixes: eaa268589e9c ("doc: man-page for the printenv command") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
The 'Configuration' heading should be on level 2, not on level 1.

Fixes: eaa268589e9c ("doc: man-page for the printenv command")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
cmd: allow sound command to play multiple sounds 2022-12-20T15:06:48+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2022-12-16T00:50:39+00:00 ea58b9a404d4cf39a3bb314804f42b213eb6d896 Currently the sound command accepts only one value each for duration and frequency. Allowing more duration and frequency arguments enables playing a tune. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Currently the sound command accepts only one value each for duration and
frequency. Allowing more duration and frequency arguments enables playing a
tune.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>