[PATCH 1/1] doc: remove illegal characters

Tue Jan 26 00:33:29 CET 2021

On 1/25/21 11:13 PM, Pali Rohár wrote:
> Hello Heinrich!
>
> Does this change mean that UTF-8 is now disallowed in U-Boot?
>
> On Monday 25 January 2021 22:48:56 Heinrich Schuchardt wrote:
>> Avoid errors when generating the HTML documentation like:
>>
>>      'ascii' codec can't decode byte 0xc2
>
> This sounds like an incorrect configuration of tool which is generating
> HTML documentation.

Sphinx uses as default:

source_encoding = 'utf-8-sig'

With Sphinx 3 on my machine I have no problem. But with Sphinx 2 on
Gitlab an error is ejected for Unicode letters.

I do not know if elder Sphinx versions require a BOM to mark a file as
UTF-8 when using utf-8-sig.

Best regards

Heinrich

>
>> Correct capitalization of 'U-Boot'.
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>> ---
>>   doc/board/freescale/b4860qds.rst    |  2 +-
>>   doc/board/microchip/mpfs_icicle.rst |  4 ++--
>>   doc/board/sifive/fu540.rst          |  2 +-
>>   doc/board/xen/xenguest_arm64.rst    | 14 +++++++-------
>>   doc/driver-model/design.rst         |  2 +-
>>   doc/usage/bootmenu.rst              |  2 +-
>>   6 files changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/doc/board/freescale/b4860qds.rst b/doc/board/freescale/b4860qds.rst
>> index de14d857b9..efb1422e1c 100644
>> --- a/doc/board/freescale/b4860qds.rst
>> +++ b/doc/board/freescale/b4860qds.rst
>> @@ -9,7 +9,7 @@ The B4860QDS is a Freescale reference board that hosts the B4860 SoC
>>   B4860 Overview
>>   --------------
>>   The B4860 QorIQ Qonverge device is a Freescale high-end, multicore SoC based on
>> -StarCore and Power Architecture® cores. It targets the broadband wireless
>> +StarCore and Power Architecture cores. It targets the broadband wireless
>>   infrastructure and builds upon the proven success of the existing multicore
>>   DSPs and Power CPUs. It is designed to bolster the rapidly changing and
>>   expanding wireless markets, such as 3GLTE (FDD and TDD), LTE-Advanced, and UMTS.
>> diff --git a/doc/board/microchip/mpfs_icicle.rst b/doc/board/microchip/mpfs_icicle.rst
>> index c71c2f3cab..1f9ce13a3c 100644
>> --- a/doc/board/microchip/mpfs_icicle.rst
>> +++ b/doc/board/microchip/mpfs_icicle.rst
>> @@ -702,9 +702,9 @@ Sample boot log from MPFS Icicle Kit
>>      [    2.756098] systemd[1]: Created slice User and Session Slice.
>>      [  OK  ] Created slice User and Session Slice.
>>      [    2.789065] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
>> -   [  OK  ] Started Dispatch Password …ts to Console Directory Watch.
>> +   [  OK  ] Started Dispatch Password ..ts to Console Directory Watch.
>>      [    2.828974] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
>> -   [  OK  ] Started Forward Password R…uests to Wall Directory Watch.
>> +   [  OK  ] Started Forward Password R..uests to Wall Directory Watch.
>>      [    2.869009] systemd[1]: Reached target Paths.
>>      [  OK  ] Reached target Paths.
>>      [    2.898808] systemd[1]: Reached target Remote File Systems.
>> diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
>> index 4e4c852ff3..c8091f6490 100644
>> --- a/doc/board/sifive/fu540.rst
>> +++ b/doc/board/sifive/fu540.rst
>> @@ -5,7 +5,7 @@ HiFive Unleashed
>>
>>   FU540-C000 RISC-V SoC
>>   ---------------------
>> -The FU540-C000 is the world’s first 4+1 64-bit RISC-V SoC from SiFive.
>> +The FU540-C000 is the world's first 4+1 64-bit RISC-V SoC from SiFive.
>>
>>   The HiFive Unleashed development platform is based on FU540-C000 and capable
>>   of running Linux.
>> diff --git a/doc/board/xen/xenguest_arm64.rst b/doc/board/xen/xenguest_arm64.rst
>> index 1327f88f99..31a5c23dfd 100644
>> --- a/doc/board/xen/xenguest_arm64.rst
>> +++ b/doc/board/xen/xenguest_arm64.rst
>> @@ -6,17 +6,17 @@ Xen guest ARM64 board
>>   This board specification
>>   ------------------------
>>
>> -This board is to be run as a virtual Xen [1] guest with U-boot as its primary
>> +This board is to be run as a virtual Xen [1] guest with U-Boot as its primary
>>   bootloader. Xen is a type 1 hypervisor that allows multiple operating systems
>>   to run simultaneously on a single physical server. Xen is capable of running
>>   virtual machines in both full virtualization and para-virtualization (PV)
>> -modes. Xen runs virtual machines, which are called “domains”.
>> +modes. Xen runs virtual machines, which are called "domains".
>>
>>   Paravirtualized drivers are a special type of device drivers that are used in
>>   a guest system in the Xen domain and perform I/O operations using a special
>>   interface provided by the virtualization system and the host system.
>>
>> -Xen support for U-boot is implemented by introducing a new Xen guest ARM64
>> +Xen support for U-Boot is implemented by introducing a new Xen guest ARM64
>>   board and porting essential drivers from MiniOS [3] as well as some of the work
>>   previously done by NXP [4]:
>>
>> @@ -39,7 +39,7 @@ previously done by NXP [4]:
>>   Board limitations
>>   -----------------
>>
>> -1. U-boot runs without MMU enabled at the early stages.
>> +1. U-Boot runs without MMU enabled at the early stages.
>>      According to Xen on ARM ABI (xen/include/public/arch-arm.h): all memory
>>      which is shared with other entities in the system (including the hypervisor
>>      and other guests) must reside in memory which is mapped as Normal Inner
>> @@ -54,14 +54,14 @@ Board limitations
>>   2. No serial console until MMU is up.
>>      Because data cache maintenance is required until the MMU setup the
>>      early/debug serial console is not implemented. Therefore, we do not have
>> -   usual prints like U-boot’s banner etc. until the serial driver is
>> +   usual prints like U-Boot's banner etc. until the serial driver is
>>      initialized.
>>
>>   3. Single RAM bank supported.
>>      If a Xen guest is given much memory it is possible that Xen allocates two
>>      memory banks for it. The first one is allocated under 4GB address space and
>> -   in some cases may represent the whole guest’s memory. It is assumed that
>> -   U-boot most likely won’t require high memory bank for its work andlaunching
>> +   in some cases may represent the whole guest's memory. It is assumed that
>> +   U-Boot most likely won't require high memory bank for its work andlaunching
>>      OS, so it is enough to take the first one.
>>
>>
>> diff --git a/doc/driver-model/design.rst b/doc/driver-model/design.rst
>> index ffed7d5f79..93a9f3dc41 100644
>> --- a/doc/driver-model/design.rst
>> +++ b/doc/driver-model/design.rst
>> @@ -10,7 +10,7 @@ by:
>>
>>      * Marek Vasut <marex at denx.de>
>>      * Pavel Herrmann <morpheus.ibis at gmail.com>
>> -   * Viktor Křivák <viktor.krivak at gmail.com>
>> +   * Viktor Krivak <viktor.krivak at gmail.com>
>>      * Tomas Hlavacek <tmshlvck at gmail.com>
>>
>>   This has been both simplified and extended into the current implementation
>> diff --git a/doc/usage/bootmenu.rst b/doc/usage/bootmenu.rst
>> index 1f094ad6ed..44654acced 100644
>> --- a/doc/usage/bootmenu.rst
>> +++ b/doc/usage/bootmenu.rst
>> @@ -1,5 +1,5 @@
>>   .. SPDX-License-Identifier: GPL-2.0+
>> -.. (C) Copyright 2011-2012 Pali Rohár <pali at kernel.org>
>> +.. (C) Copyright 2011-2012 Pali Rohar <pali at kernel.org>
>>
>>   bootmenu command
>>   ================
>> --
>> 2.29.2
>>