[PATCH 1/3] Documentation: devel: background-execution: update section on I2C slices

[PATCH 1/3] Documentation: devel: background-execution: update section on I2C slices

[Ahmad Fatoum]

When the documentation was written, there were no I2C slices yet.
The example is still useful to explain why slices need to be used, so
we'll leave it in, but update the documentation to reflect that slices
are indeed used now in I2C code.

Fixes: 51ae3151381b ("i2c: Add slices for I2C adapters")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 Documentation/devel/background-execution.rst | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/devel/background-execution.rst b/Documentation/devel/background-execution.rst
index d379593efb23..cf8675b9aa0e 100644
--- a/Documentation/devel/background-execution.rst
+++ b/Documentation/devel/background-execution.rst
@@ -131,12 +131,14 @@ executed nothing else happens. This means that when fastboot flashes an image
 in a workqueue then barebox won't react to any key presses on the command line.
 The usage of the interfaces described in this document is not yet very
 widespread in barebox. The interfaces are used in the places where we need
-them, but there are other places which do not use them but should. For example
-using a LED driven by a I2C GPIO exander used as hearbeat LED won't work
-properly currently. Consider the I2C driver accesses an unrelated I2C device,
+them, but there are other places which do not use them but should.
+
+For example using a LED driven by a I2C GPIO expander used as hearbeat LED
+used to not work properly before addition of slices.
+Consider the I2C driver accesses an unrelated I2C device,
 like an EEPROM. After having initiated the transfer the driver polls for the
 transfer being completed using a ``is_timeout()`` loop. The call to
 ``is_timeout()`` then calls into the registered pollers from which one accesses
 the same I2C bus whose driver is just polling for completion of another
-transfer. With this the I2C driver is in an undefined state and will likely not
-work anymore.
+transfer. Without slices, this left the I2C driver in an undefined state,
+where it would likely not work anymore.
-- 
2.39.2

[PATCH 2/3] Documentation: user: intro: add more info about mailing list

[Ahmad Fatoum]

We don't actually list the mailing list address, just a link to
mailman.

The link to the Linux kernel patch submission guide should also be
located here and not only in the README.

Finally, a reference to the Github Actions is also appropriate.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 Documentation/user/introduction.rst | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/user/introduction.rst b/Documentation/user/introduction.rst
index 63a4c29cba67..d68b57e50333 100644
--- a/Documentation/user/introduction.rst
+++ b/Documentation/user/introduction.rst
@@ -21,7 +21,8 @@ Feedback
 --------
 
 For sending patches, asking for help and giving general feedback you are
-always welcome to write an e-mail to the barebox mailing list. Most of the
+always welcome to write an e-mail to the barebox mailing list at
+<mailto:barebox@lists.infradead.org>. Most of the
 discussion of barebox takes place here:
 
 http://lists.infradead.org/mailman/listinfo/barebox/
@@ -29,10 +30,18 @@ http://lists.infradead.org/mailman/listinfo/barebox/
 Mails sent to the barebox mailing list are archived on
 `lore.barebox.org <https://lore.barebox.org/barebox/>`_.
 
+barebox uses a similar patch process as the Linux kernel, so most of the
+`Linux guide for submitting patches <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_
+also applies to barebox, except forthe need to select your recipient;
+all barebox patches go to the same list.
+
 Patch series sent there can be applied with `b4 <https://pypi.org/project/b4/>`_ ::
 
    git config b4.midmask https://lore.barebox.org/%s
    git config b4.linkmask https://lore.barebox.org/%s
    b4 shazam -M https://lore.barebox.org/$messageid # replace with link
 
+CI tests are executed by Github Actions an be used by forking
+`the project on Github <https://github.com/barebox/barebox>`.
+
 There's also an IRC channel: #barebox on Libera Chat
-- 
2.39.2

[PATCH 3/3] README: bring it up to date

[Ahmad Fatoum]

Most of the file was written when barebox used to be called U-Boot v2.
It thus focused on comparisons and highlighted some aspects that
U-Boot has since adopted.

Give the file an overhaul by converting it to ReST and highlight
my subjective take on what makes barebox cool in 2024.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
 README     | 271 -------------------------------------------
 README.rst | 328 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 328 insertions(+), 271 deletions(-)
 delete mode 100644 README
 create mode 100644 README.rst

diff --git a/README b/README
deleted file mode 100644
index 37fd80c10280..000000000000
--- a/README
+++ /dev/null
@@ -1,271 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-
-barebox
--------
-
-barebox is a bootloader that follows the tradition of Das U-Boot, while
-adopting modern design ideas from the Linux kernel.
-
-
-Features
---------
-
-- A POSIX-based file API
-  Inside barebox the usual open/close/read/write/lseek functions are used.
-  This makes it familiar to everyone who has programmed under UNIX systems.
-
-- Usual shell commands like ls/cd/mkdir/echo/cat,...
-
-- The environment is not a variable store anymore, but a file store. It has
-  currently some limitations, of course. The environment is not a real
-  read/write filesystem, but more like a tar archive.
-  The saveenv command saves the files under a certain directory (by default
-  /env) in persistent storage (by default /dev/env0). There is a counterpart
-  called loadenv, too.
-
-- filesystem support
-  The loader starts up with mounting a ramdisk on /. Then a devfs is mounted
-  on /dev allowing the user (or shell commands) to access devices. Apart from
-  these two filesystems there are a number of different filesystems ported:
-  ext4, efi, efivarfs, ext4, fat, jffs2, NFS, pstore, squashfs, ubifs,
-  u-boot variable FS among others.
-
-- device/driver model
-  Devices are no longer described by defines in the config file. Instead
-  devices are registered as they are discovered (e.g. through OpenFirmware
-  device tree traversal or EFI handles) or by board code.
-  Drivers will match upon the devices automatically.
-
-- clocksource support
-  Timekeeping has been simplified by the use of the Linux clocksource API.
-  no [gs]et_timer[masked]() or reset_timer[masked]() functions.
-
-- Kconfig and Kernel build system
-  Only targets which are really needed get recompiled. Parallel builds are
-  no problem anymore. This also removes the need for many many ifdefs in
-  the code.
-
-- ARCH=sandbox simulation target
-  barebox can be compiled to run under Linux. While this is rather useless
-  in real world this is a great debugging and development aid. New features
-  can be easily developed and tested on long train journeys and started
-  under gdb. There is a console driver for Linux which emulates a serial
-  device and a TAP-based Ethernet driver. Linux files can be mapped to
-  devices under barebox to emulate storage devices.
-
-- device parameter support
-  Each device can have an unlimited number of parameters. They can be accessed
-  on the command line with <devid>.<param>="...", for example
-  'eth0.ip=192.168.0.7' or 'echo $eth0.ip'
-
-- initcalls
-  hooks in the startup process can be achieved with *_initcall() directives
-  in each file.
-
-- getopt
-  There is a small getopt implementation. Some commands got really
-  complicated (both in code and in usage) due to the fact that U-Boot
-  allowed only positional parameters.
-
-- editor
-  Scripts can be edited with a small editor. This editor has no features
-  except the ones really needed: moving the cursor and typing characters.
-
-
-Building barebox
-----------------
-
-barebox uses the Linux kernel's build system. It consists of two parts:
-the Makefile infrastructure (kbuild), plus a configuration system
-(kconfig). So building barebox is very similar to building the Linux
-kernel.
-
-For the examples below, we use the User Mode barebox implementation, which
-is a port of barebox to the Linux userspace. This makes it possible to
-test drive the code without having real hardware. So for this test
-scenario, ARCH=sandbox is the valid architecture selection. This currently
-works on at least IA32 hosts and x86-64 hosts.
-
-Selection of the architecture and the cross compiler can be done by using
-the environment variables ARCH and CROSS_COMPILE.
-
-In order to configure the various aspects of barebox, start the barebox
-configuration system:
-
-  # make menuconfig
-
-This command starts a menu box and lets you select all the different
-options available for your architecture. Once the configuration was
-finished (you can simulate this by using the standard demo config file
-with 'make sandbox_defconfig'), there is a .config file in the toplevel
-directory of the source code.
-
-Once barebox is configured, we can start the compilation
-
-  # make
-
-If everything goes well, the result is a file called barebox:
-
-  # ls -l barebox
-    -rwxr-xr-x 1 rsc ptx 114073 Jun 26 22:34 barebox
-
-barebox usually needs an environment for storing the configuration data.
-You can generate an environment using the example environment contained
-in board/sandbox/env:
-
-  # ./scripts/bareboxenv -s -p 0x10000 arch/sandbox/board/env env.bin
-
-To get some files to play with, you can generate a cramfs image:
-  # mkcramfs somedir/ cramfs.bin
-
-The barebox image is a normal Linux executable, so it can be started
-just like every other program:
-
-  # ./barebox -e env.bin -i cramfs.bin
-
-  barebox 2.0.0-trunk (Jun 26 2007 - 22:34:38)
-
-  loading environment from /dev/env0
-  barebox> /
-
-Specifying -[ie] <file> tells barebox to map the file as a device
-under /dev. Files given with '-e' will appear as /dev/env[n]. Files
-given with '-i' will appear as /dev/fd[n].
-
-If barebox finds a valid configuration sector on /dev/env0 it will
-load it to /env. It then executes /env/init if it exists. If you have
-loaded the example environment, barebox will show you a menu asking for
-your settings.
-
-If you have started barebox as root, you will find a new tap device on your
-host which you can configure using ifconfig. Once you configured barebox'
-network settings accordingly you can do a ping or tftpboot.
-
-If you have mapped a cramfs image, try mounting it with
-
-  # mkdir /cram
-  # mount /dev/fd0 cramfs /cram
-
-Memory can be examined as usual using md/mw commands. They both understand
-the -f <file> option to tell the commands that they should work on the
-specified files instead of /dev/mem which holds the complete address space.
-Note that if you call 'md /dev/fd0' (without -f) barebox will segfault on
-the host, because it will interpret /dev/fd0 as a number.
-
-
-Directory Layout
-----------------
-
-Most of the directory layout is based upon the Linux Kernel:
-
-arch/*                -> contains architecture specific parts
-arch/*/include        -> architecture specific includes
-arch/*/mach-*         -> SoC specific code
-arch/*/mach-*/include -> SoC specific includes
-
-drivers/serial        -> drivers
-drivers/net
-drivers/...
-
-fs/                   -> filesystem support and filesystem drivers
-
-lib/                  -> generic library functions (getopt, readline and the
-                         like)
-
-common/               -> common stuff
-
-commands/             -> many things previously in common/cmd_*, one command
-			 per file
-
-net/                  -> Networking stuff
-
-scripts/              -> Kconfig system
-
-Documentation/        -> Sphinx generated documentation. Call "make docs" to
-                         generate a HTML version in Documentation/html.
-
-
-Release Strategy
-----------------
-
-barebox is developed with git. On a monthly schedule, tarball releases are
-branched from the repository and released on the project web site. Here
-are the release rules:
-
-- Releases follow a time based scheme:
-
-  barebox-xxxx.yy.z.tar.bz2
-          ^^^^ ^^ ^----------- Bugfix Number, starting at 0
-            \   \------------- Month
-             \---------------- Year
-
-  Example: barebox-2009.12.0.tar.bz2
-
-- Releases are made around the beginning of the month. As we are aiming
-  for monthly releases, development is considered to be a continuous
-  process. If you find bugs in one release, you have the chance to get
-  patches in on a very short time scale.
-
-- Usually, there are no bugfix releases, so z=0. If there is a need
-  to make a bugfix release, z is the right place to increment.
-
-- If there may be a reason for pre releases, they are called
-
-  barebox-xxxx.yy.z-pren.tar.bz
-                       ^------ Number of prerelease, starting with 1
-
-  Example: barebox-2009.12.0-pre1.tar.bz2
-
-  We think that there is no need for pre releases, but if it's ever
-  necessary, this is the scheme we follow.
-
-- Only the monthly releases are archived on the web site. The tarballs
-  are located in https://www.barebox.org/download/ and this location
-  does never change, in order to make life easier for distribution
-  people.
-
-
-Contributing
-------------
-
-For any questions regarding barebox, send a mail to the mailing list at
-<barebox@lists.infradead.org>. The archives for this list are available
-publicly at <http://lists.infradead.org/pipermail/barebox/> and
-<https://lore.barebox.org/barebox/>.
-
-The same list should also be used to send patches. barebox uses a similar
-process as the Linux kernel, so most of the Linux guide for submitting patches
-<https://www.kernel.org/doc/html/latest/process/submitting-patches.html> also
-applies to barebox (except the step for selecting your recipient - we don't
-have a MAINTAINERS file, instead all patches go to the list).
-
-
-License
--------
-
-Copyright (C) 2000 - 2005 Wolfgang Denk, DENX Software Engineering, wd@denx.de.
-Copyright (C) 2018 Sascha Hauer, Pengutronix, and individual contributors
-
-barebox is free software: you can redistribute it and/or modify it under the
-terms of the GNU General Public License, version 2, as published by the Free
-Software Foundation.
-
-This program is distributed in the hope that it will be useful, but WITHOUT ANY
-WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
-PARTICULAR PURPOSE. See the GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License in the file
-COPYING along with this program. If not, see <https://www.gnu.org/licenses/>.
-
-Individual files may contain the following SPDX license tags as a shorthand for
-the above copyright and warranty notices:
-
-    SPDX-License-Identifier: GPL-2.0-only
-    SPDX-License-Identifier: GPL-2.0-or-later
-
-This eases machine processing of licensing information based on the SPDX
-License Identifiers that are available at http://spdx.org/licenses/.
-
-Also note that some files in the barebox source tree are available under
-several different GPLv2-compatible open-source licenses. This fact is noted
-clearly in the file headers of the respective files.
diff --git a/README.rst b/README.rst
new file mode 100644
index 000000000000..17bf288c4c60
--- /dev/null
+++ b/README.rst
@@ -0,0 +1,328 @@
+..
+  SPDX-License-Identifier: GPL-2.0-only
+
+=======
+barebox
+=======
+
+A bootloader that follows the tradition of Das U-Boot, while
+adopting modern design ideas from the Linux kernel.
+
+.. class:: center
+
+`Try it out in your browser ✨ <https://www.barebox.org/jsbarebox/?graphic=0>`_
+·
+`Check out the documentation 📖 <https://www.barebox.org/doc/latest/index.html>`_
+·
+`Get involved 🫶 <https://www.barebox.org/doc/latest/user/introduction.html#feedback>`_
+
+Features
+--------
+
+* A POSIX-based file API:
+  Inside barebox the usual ``open/close/read/write/lseek`` functions are used.
+  This makes it familiar to everyone who has programmed under UNIX systems.
+
+* Usual shell commands like ``ls/cd/mkdir/echo/cat/cp/mount``,...
+  which work uniformly across file systems
+
+* Filesystem support:
+  The loader starts up with mounting a ramdisk on ``/``. Then a devfs is mounted
+  on ``/dev`` allowing the user (or shell commands) to access devices. Apart from
+  these two filesystems there are a number of different filesystems ported:
+  ext4, efi, efivarfs, ext4, fat, jffs2, NFS, tftp, pstore, squashfs, ubifs,
+  ratp (RFC916), u-boot variable FS among others.
+
+* Multiplatform support:
+  Configurations like ``multi_v7_defconfig`` and ``multi_v8_defconfig`` build
+  barebox for many dozens of boards all at once. All resulting images share the
+  same barebox proper binary, each time with a different prebootloader that does
+  low-level initialization and passes in the device tree. Prebootloaders may
+  detect board/SoC type and pass in different device trees to support various
+  boards with the same image.
+
+* Focus on developer experience:
+  barebox provides many features that should be familiar to kernel developers
+
+  * barebox images are designed to be bootable from within barebox itself,
+    so developers can trivially network boot. For chainloading from existing
+    bootloaders, there's also an extra ``barebox-dt-2nd.img`` that is bootable
+    exactly like a Linux kernel.
+  * KASAN (KernelAddressSanitizer) and kallsyms (symbolized stack traces)
+    help in hunting down memory issues
+  * ramoops allows barebox to share its own ``dmesg`` log with Linux
+  * Linux kernel drivers are easier to port, because the driver frameworks are
+    closely based on the upstream Linux counterpart
+
+* Device parameter support:
+  Each device can have an unlimited number of parameters. They can be accessed
+  on the command line with ``<devid>.<param>="..."``, for example
+  ``eth0.ip=192.168.0.7`` or echo ``$eth0.ip``.
+
+* Editor:
+  Scripts can be edited with a small editor. This editor has no features
+  except the ones really needed: moving the cursor and typing characters
+  on multiple lines.
+
+* The environment is not a variable store anymore, but a file store.
+  The ``saveenv`` command archives the files under a certain directory (by default
+  ``/env``) in persistent storage (by default ``/dev/env0``). There is a counterpart
+  called ``loadenv``, too. Additionally, barebox-state provides power-fail-safe
+  variable-only storage with optional authentication, so the mutable environment
+  can be disabled for security reasons.
+
+* Uniformity: Finding out where barebox booted from, determining what caused
+  the last reset, booting in a redundant fail-safe manner, updating barebox on disk
+  are examples of functionality handled generically by frameworks, so boards can look
+  and feel the same and custom scripts or board code are only needed for the
+  exceptional stuff.
+
+* device/driver model:
+  Devices are no longer described by defines in the config file. Instead
+  devices are registered as they are discovered (e.g. through OpenFirmware
+  device tree traversal or EFI handles) or by board code.
+  Drivers will match upon the devices automatically.
+
+* Device Tree Manipulation:
+  barebox has extensive support for fixing up both its own device tree at
+  runtime and the kernel's, whether from board code, shell scripts or within
+  device tree overlays
+
+* Initcalls:
+  hooks in the startup process can be achieved with ``*_initcall()`` directives
+  in each file.
+
+* ``ARCH=sandbox`` simulation target:
+  barebox can be compiled to run under Linux. While this is rather useless
+  in real world this is a great debugging and development aid. New features
+  can be easily developed and tested on long train journeys and started
+  under gdb. There is a console driver for Linux which emulates a serial
+  device and a TAP-based Ethernet driver. Linux files can be mapped to
+  devices under barebox to emulate storage devices.
+
+* and `yes, of course it runs DOOM <https://doomwiki.org/wiki/BareDOOM>`_.
+
+Building barebox
+----------------
+
+barebox uses the Linux kernel's build system. It consists of two parts:
+the Makefile infrastructure (kbuild), plus a configuration system
+(kconfig). So building barebox is very similar to building the Linux
+kernel.
+
+For the examples below, we use the User Mode barebox implementation, which
+is a port of barebox to the Linux userspace. This makes it possible to
+test drive the code without having real hardware. So for this test
+scenario, ``ARCH=sandbox`` is the valid architecture selection. This currently
+works on at least IA32 hosts and x86-64 hosts.
+
+Selection of the architecture and the cross compiler can be done by using
+the environment variables ``ARCH`` and ``CROSS_COMPILE``.
+
+In order to configure the various aspects of barebox, start the barebox
+configuration system::
+
+  # make menuconfig
+
+This command starts a menu box and lets you select all the different
+options available for your architecture. Once the configuration was
+finished (you can simulate this by using the standard demo config file
+with ``make sandbox_defconfig``), there is a ``.config`` file in the
+toplevel directory of the source code.
+
+Once barebox is configured, we can start the compilation::
+
+  # make
+
+If everything goes well, the result is a file called barebox::
+
+  # ls -l barebox
+    -rwxr-xr-x 1 rsc ptx 114073 Jun 26 22:34 barebox
+
+To get some files to play with, you can generate a squashfs image::
+
+  # mksquashfs somedir/ squashfs.bin
+
+The barebox image is a normal Linux executable, so it can be started
+just like every other program::
+
+  # ./barebox -i squashfs.bin
+
+  add fd0 backed by file squashfs.bin
+  add stickypage backed by file /run/user/1000/barebox/stickypage.1661112
+
+  barebox 2024.07.0 #0 Wed Jul 18 11:36:31 CEST 2024
+  [...]
+
+  barebox@Sandbox:/
+
+Specifying ``-[ie] <file>`` tells barebox to map the file as a device
+under /dev. Files given with ``-e`` will appear as ``/dev/env[n]``. Files
+given with ``-i`` will appear as ``/dev/fd[n]``.
+
+If barebox finds a valid configuration sector on ``/dev/env0`` it will
+load it to ``/env``. It then source ``/env/init/*`` if it exists. If you have
+loaded the example environment, barebox will show you a menu asking for
+your settings. The sandbox configuration embeds a "sticky page", which is
+inherited across barebox resets. This way, there's a usable environment
+out-of-the-box.
+
+If you have started barebox as root, you will find a new tap device on your
+host which you can configure using ifconfig. Once you configured barebox'
+network settings accordingly you can do a ping or tftpboot.
+
+If you have mapped a squashfs image, try mounting it with::
+
+  barebox@Sandbox:/ mount fd0
+  mounted /dev/fd0 on /mnt/fd0
+
+When called with a single argument, the barebox ``mount`` command will inspect
+the source device file's magic bytes and mount it with the appropriate file system
+under ``/mnt``.
+
+Memory can be examined as usual using md/mw commands. They understand
+the ``-s <file>`` and ``-d <file>`` options respectively to tell the commands
+that they should work on the specified files instead of ``/dev/mem`` which holds
+the complete address space.
+
+Directory Layout
+----------------
+
+Most of the directory layout is based upon the Linux Kernel
+
+.. list-table::
+
+  * - | ``arch/*``
+      | ``arch/*/include``
+      | ``arch/*/mach-*``
+      | ``include/mach/*``
+    - | contains architecture specific parts
+      | architecture specific includes
+      | SoC specific code
+      | SoC specific includes
+
+  * - | ``drivers/serial``
+      | ``drivers/net/dsa/``
+      | ``drivers/...``
+    - | drivers
+
+  * - | ``fs/``
+    - | filesystem support and filesystem drivers
+
+  * - | ``lib/``
+    - | generic library functions (getopt, readline and the like)
+
+  * - | ``common/``
+      | ``common/boards``
+    - | common stuff
+      | board code shared between multiple boards (possibly of different architectures)
+
+  * - | ``commands/``
+    - | Commands that can be executed by the barebox shell
+
+  * - | ``net/``
+    - | Networking stuff
+
+  * - | ``scripts/``
+    - | Kconfig system and tools used during barebox build or for deploying it
+
+  * - | ``Documentation/``
+    - | Sphinx generated documentation. Call "make docs" to generate a HTML version in Documentation/html.
+
+  * - | ``defaultenv/``
+    - | default environment assembled into images. Board environment is overlaid on top
+
+  * - | ``dts/``
+    - | An import of the upstream device tree repository maintained as part of the Linux kernel
+
+Release Strategy
+----------------
+
+barebox is developed with git. On a monthly schedule, tarball releases are
+branched from the repository and released on the project web site. Here
+are the release rules:
+
+- Releases follow a time based scheme::
+
+    barebox-xxxx.yy.z.tar.bz2
+            ^^^^ ^^ ^----------- Bugfix Number, starting at 0
+              \   \------------- Month
+               \---------------- Year
+
+  Example: barebox-2024.08.0.tar.bz2
+
+- As we are aiming for monthly releases, development is considered to be
+  a continuous process. If you find bugs in one release, you have the chance
+  to get patches in on a very short time scale (usually a month at most).
+
+- New features are applied to the ``next`` branch. Fixes directly to the
+  ``master`` branch. Releases are always branched from ``master`` and then
+  ``next`` is merged into ``master``. Thus new features take 1-2 months
+  until they hit a release.
+
+- Usually, there are no bugfix releases, so z=0. If there is a need
+  to make a bugfix release, z is the right place to increment.
+
+- If there may be a reason for pre releases, they are called ::
+
+    barebox-xxxx.yy.z-pren.tar.bz
+                         ^------ Number of prerelease, starting with 1
+
+  Example: barebox-2009.12.0-pre1.tar.bz2
+
+  We think that there is no need for pre releases, but if it's ever
+  necessary, this is the scheme we follow.
+
+- Only the monthly releases are archived on the web site. The tarballs
+  are located in https://www.barebox.org/download/ and this location
+  does never change, in order to make life easier for distribution
+  people.
+
+.. _contributing:
+
+Contributing
+------------
+
+barebox collaboration happens chiefly on the
+<barebox@lists.infradead.org> mailing list.
+
+The repository can be forked on `Github <https://github.com/barebox/barebox>`
+to run the CI test suite against the virtualized targets before submitting
+patches.
+
+Refer to the
+`introduction section <https://www.barebox.org/doc/latest/user/introduction.html#feedback>`_
+in the documentation for more information.
+
+License
+-------
+
+| Copyright (C) 2000 - 2005 Wolfgang Denk, DENX Software Engineering, wd@denx.de.
+| Copyright (C) 2018 Sascha Hauer, Pengutronix, and individual contributors
+|
+
+
+barebox is free software: you can redistribute it and/or modify it under the
+terms of the GNU General Public License, version 2, as published by the Free
+Software Foundation.
+
+This program is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License in the file
+COPYING along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+Individual files may contain the following SPDX license tags as a shorthand for
+the above copyright and warranty notices::
+
+    SPDX-License-Identifier: GPL-2.0-only
+    SPDX-License-Identifier: GPL-2.0-or-later
+
+This eases machine processing of licensing information based on the SPDX
+License Identifiers that are available at http://spdx.org/licenses/.
+
+Also note that some files in the barebox source tree are available under
+several different GPLv2-compatible open-source licenses. This fact is noted
+clearly in the file headers of the respective files and the full license
+text is reproduced in the ``LICENSES/`` directory.
-- 
2.39.2

Re: [PATCH 1/3] Documentation: devel: background-execution: update section on I2C slices

[Sascha Hauer]

On Fri, 09 Aug 2024 16:24:42 +0200, Ahmad Fatoum wrote:
> When the documentation was written, there were no I2C slices yet.
> The example is still useful to explain why slices need to be used, so
> we'll leave it in, but update the documentation to reflect that slices
> are indeed used now in I2C code.
> 
> 

Applied, thanks!

[1/3] Documentation: devel: background-execution: update section on I2C slices
      https://git.pengutronix.de/cgit/barebox/commit/?id=e5e2fb6658a0 (link may not be stable)
[2/3] Documentation: user: intro: add more info about mailing list
      https://git.pengutronix.de/cgit/barebox/commit/?id=3449c1ee700c (link may not be stable)
[3/3] README: bring it up to date
      https://git.pengutronix.de/cgit/barebox/commit/?id=e851f9baa8a3 (link may not be stable)

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>

Re: [PATCH 3/3] README: bring it up to date

[Sascha Hauer]

On Fri, Aug 09, 2024 at 04:24:44PM +0200, Ahmad Fatoum wrote:
> Most of the file was written when barebox used to be called U-Boot v2.
> It thus focused on comparisons and highlighted some aspects that
> U-Boot has since adopted.
> 
> Give the file an overhaul by converting it to ReST and highlight
> my subjective take on what makes barebox cool in 2024.

This was overdue. The result reads really good :)

Thanks for working on this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |