[PULL u-boot] Please pull u-boot-amlogic-20201005
Hi Tom, This PR adds proper USB OTG support for GXL/GXM and AXG based boards with Linux 5.8 DT sync, adds dynamic PCIe enable in OS DT for the VIM3/VIM3L boards with Linux 5.9 DT sync, AXG pinctrl fixes, introduces the Amlogic PWM driver and enables an unique mac address from SoC serial on S400 board. The CI job is at https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/4915 Thanks, Neil The following changes since commit 050acee119b3757fee3bd128f55d720fdd9bb890: Prepare v2020.10 (2020-10-05 11:15:32 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20201005 for you to fetch changes up to 2d481b2e3e22f7be854d381a7bafd92a65e18b23: pwm: Add driver for Amlogic Meson PWM controller (2020-10-05 18:02:16 +0200) - generate unique mac address from SoC serial on S400 board - Add USB support for GXL and AXG SoCs - Update Gadget code to use the new GXL and AXG USB glue driver - Add a VIM3 board support to add dynamic PCIe enable in OS DT - Fix AXG pinmux with requesting GPIOs - Add missing GPIOA_18 for AXG pinctrl - Add Amlogic PWM driver Neil Armstrong (16): board: s400: generate unique mac address from SoC serial ARM: dts: sync amlogic AXG/GXL/GXM DT from Linux 5.8-rc1 usb: dwc3: add Amlogic GXL & GXL DWC3 Glue ARM: mach-meson: use new DWC3 glue for GXL & GXM phy: meson-gxl: remove invalid USB3 PHY driver phy: meson-gxl-usb: depend on Meson AXG aswell arm: meson-axg: add board_usb_init()/cleanup() for USB gadget ARM: dts: meson-axg: add USB nodes for S400 configs: s400: enable USB ARM: dts: sync amlogic G12A/SM1 DT from Linux 5.9-rc1 board: amlogic: add a vim3 specific board support configs: vim3: use the vim3 board support board: amlogic: vim3: add support for dynamic PCIe enable pinctrl: meson-axg-pmx: fix gpio request pinctrl: meson-axg: add missing GPIOA_18 pwm: Add driver for Amlogic Meson PWM controller arch/arm/dts/meson-axg-s400-u-boot.dtsi| 12 + arch/arm/dts/meson-axg-u-boot.dtsi | 62 +++ arch/arm/dts/meson-axg.dtsi| 6 +- arch/arm/dts/meson-g12-common.dtsi | 55 ++- arch/arm/dts/meson-g12b-odroid-n2.dts | 136 +- arch/arm/dts/meson-gx-libretech-pc.dtsi| 78 ++- arch/arm/dts/meson-gx.dtsi | 23 +- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 2 +- arch/arm/dts/meson-gxbb-odroidc2.dts | 2 +- arch/arm/dts/meson-gxbb.dtsi | 23 + .../dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi | 4 - arch/arm/dts/meson-gxl-s805x-libretech-ac.dts | 73 ++- .../dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi | 4 - .../arm/dts/meson-gxl-s905x-khadas-vim-u-boot.dtsi | 4 - arch/arm/dts/meson-gxl-s905x-khadas-vim.dts| 4 + .../dts/meson-gxl-s905x-libretech-cc-u-boot.dtsi | 4 - arch/arm/dts/meson-gxl-s905x-libretech-cc.dts | 77 ++- arch/arm/dts/meson-gxl-s905x-p212.dtsi | 3 +- arch/arm/dts/meson-gxl-u-boot.dtsi | 16 - arch/arm/dts/meson-gxl.dtsi| 79 ++- arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi | 4 - arch/arm/dts/meson-gxm-khadas-vim2.dts | 3 +- .../dts/meson-gxm-s912-libretech-pc-u-boot.dtsi| 4 - arch/arm/dts/meson-gxm.dtsi| 7 +- arch/arm/dts/meson-khadas-vim3.dtsi| 26 +- arch/arm/dts/meson-sm1-khadas-vim3l.dts| 92 arch/arm/dts/meson-sm1-odroid-c4.dts | 88 arch/arm/include/asm/arch-meson/usb-gx.h | 3 +- arch/arm/mach-meson/board-axg.c| 128 + arch/arm/mach-meson/board-gx.c | 127 ++--- board/amlogic/s400/s400.c | 2 + board/amlogic/vim3/MAINTAINERS | 9 + board/amlogic/vim3/Makefile| 6 + board/amlogic/vim3/khadas-mcu.h| 81 board/amlogic/vim3/vim3.c | 137 ++ board/amlogic/w400/MAINTAINERS | 4 - configs/khadas-vim2_defconfig | 2 +- configs/khadas-vim3_defconfig | 5 +- configs/khadas-vim3l_defconfig | 5 +- configs/khadas-vim_defconfig | 2 +- configs/libretech-ac_defconfig | 2 +- configs/libretech-cc_defconfig | 2 +- configs/libretech-s905d-pc_defconfig | 2 +- configs/libretech-s912-pc_defconfig| 2 +- configs/p212_defconfig | 2 +- configs/s400_defconfig | 15 + d
Re: [PATCH v3] usb: dwc2: Fix control OUT transfer issue
On 10/6/20 4:55 AM, Chance.Yang wrote: > In buffer DMA mode, gadget should re-configure EP 0 to received SETUP > packets when doeptsiz.xfersize is equal to a setup packet size(8 bytes) > and EP 0 is in WAIT_FOR_SETUP state. > > Since EP 0 is not enabled in WAIT_FOR_SETUP state, SETUP packets is NOT > received from RxFifo and wriiten to the external memory. Applied, thanks.
[PATCH 1/1] Create codeql-analysis.yml
Enable CodeQL Analysis on Github.
CodeQL produces a static code analysis.
Signed-off-by: Heinrich Schuchardt
---
I am not sure that everybody wants this enabled on his Github repository.
But we should look into the warnings.
You can see example output here:
https://github.com/xypron2/u-boot/security/code-scanning
---
.github/workflows/codeql-analysis.yml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 .github/workflows/codeql-analysis.yml
diff --git a/.github/workflows/codeql-analysis.yml
b/.github/workflows/codeql-analysis.yml
new file mode 100644
index 00..6035378c7a
--- /dev/null
+++ b/.github/workflows/codeql-analysis.yml
@@ -0,0 +1,72 @@
+# For most projects, this workflow file will not need changing; you simply need
+# to commit it to your repository.
+#
+# You may wish to alter this file to override the set of languages analyzed,
+# or to provide custom queries or build logic.
+name: "CodeQL"
+
+on:
+ push:
+branches: [efi-2021-01]
+ pull_request:
+# The branches below must be a subset of the branches above
+branches: [efi-2021-01]
+ schedule:
+- cron: '0 11 * * 3'
+
+jobs:
+ analyze:
+name: Analyze
+runs-on: ubuntu-latest
+
+strategy:
+ fail-fast: false
+ matrix:
+# Override automatic language detection by changing the below list
+# Supported options are ['csharp', 'cpp', 'go', 'java', 'javascript',
'python']
+language: ['cpp', 'python']
+# Learn more...
+#
https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#overriding-automatic-language-detection
+
+steps:
+- name: Checkout repository
+ uses: actions/checkout@v2
+ with:
+# We must fetch at least the immediate parents so that if this is
+# a pull request then we can checkout the head.
+fetch-depth: 2
+
+# If this run was triggered by a pull request event, then checkout
+# the head of the pull request instead of the merge commit.
+- run: git checkout HEAD^2
+ if: ${{ github.event_name == 'pull_request' }}
+
+# Initializes the CodeQL tools for scanning.
+- name: Initialize CodeQL
+ uses: github/codeql-action/init@v1
+ with:
+languages: ${{ matrix.language }}
+# If you wish to specify custom queries, you can do so here or in a
config file.
+# By default, queries listed here will override any specified in a
config file.
+# Prefix the list here with "+" to use these queries and those in the
config file.
+# queries: ./path/to/local/query, your-org/your-repo/queries@main
+
+# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
+# If this step fails, then you should remove it and run the build manually
(see below)
+# - name: Autobuild
+# uses: github/codeql-action/autobuild@v1
+
+# ℹ️ Command-line programs to run using the OS shell.
+# 📚 https://git.io/JvXDl
+
+# ✏️ If the Autobuild fails above, remove it and uncomment the following
three lines
+#and modify them (or add more) to build your code if your project
+#uses a compiled language
+
+- run: |
+ sudo apt-get install bc bison build-essential coccinelle
device-tree-compiler dfu-util flex gdisk liblz4-tool libncurses-dev libsdl2-dev
libssl-dev lzma-alone openssl swig
+ make sandbox_defconfig
+ make
+
+- name: Perform CodeQL Analysis
+ uses: github/codeql-action/analyze@v1
--
2.28.0
Re: [PATCH 1/3] mdio-uclass.c: support fixed-link subnodes
On 06/10/2020 08.02, Heiko Schocher wrote:
> Hello Rasmus,
>
> Am 05.10.2020 um 15:15 schrieb Rasmus Villemoes:
>> When trying to port our mpc8309-based board to DM_ETH, on top of
>> Heiko's patches, I found that nothing in mdio-uclass.c seems to
>> support the use of a fixed-link subnode of the ethernet DT node. That
>> is, the ethernet node looks like
>>
>> enet0: ethernet@2000 {
>> device_type = "network";
>> compatible = "ucc_geth";
>> ...
>> fixed-link {
>> reg = <0x>;
Well, it looks like that when a dummy reg property has been added, not
IRL. Sorry.
>> ---
>> net/mdio-uclass.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
>> index 66ee2e1976..2f932b77df 100644
>> --- a/net/mdio-uclass.c
>> +++ b/net/mdio-uclass.c
>> @@ -139,6 +139,12 @@ static struct phy_device
>> *dm_eth_connect_phy_handle(struct udevice *ethdev,
>> struct ofnode_phandle_args phandle = {.node = ofnode_null()};
>> int i;
>> + if (CONFIG_IS_ENABLED(PHY_FIXED) &&
>> + ofnode_valid(dev_read_subnode(ethdev, "fixed-link"))) {
>> + phy = phy_connect(NULL, -1, ethdev, interface);
>> + goto out;
>> + }
>> +
>> for (i = 0; i < PHY_HANDLE_STR_CNT; i++)
>> if (!dev_read_phandle_with_args(ethdev, phy_handle_str[i],
>> NULL,
>> 0, 0, &phandle))
>> @@ -168,6 +174,7 @@ static struct phy_device
>> *dm_eth_connect_phy_handle(struct udevice *ethdev,
>> phy = dm_mdio_phy_connect(mdiodev, phy_addr, ethdev, interface);
>> +out:
>> if (phy)
>> phy->node = phandle.node;
>
> Looks good to me... but I am not an expert in net subsystem...
> nevertheless:
>
> Reviewed-by: Heiko Schocher
Thanks.
Yeah, as I said, I have no idea if this is the right way to do things.
Some ethernet drivers seem to call phy_connect directly instead of going
through dm_eth_phy_connect(), some handle fixed-link themselves, etc.
But from a very selfish POV, this is the minimal patch to make our board
(and others with a ucc_geth ethernet dev with a fixed-link) work with
DM_ETH.
Rasmus
Re: [PATCH 0/3] DM_ETH v mpc83xx fixups
Hello Rasmus, Am 05.10.2020 um 15:15 schrieb Rasmus Villemoes: Hi Heiko I finally managed to figure out what was wrong; the fixed-link phy was simply ignored. This is fixed by the first patch, though I don't know if that's the proper way to make this work. While poking around the code I found two minor things that might as well be fixed. Thanks for the fixes (and testing)! I'd also like to do a somewhat more extensive change to dm_qe_uec.c: I find it very confusing with the qe_uec_priv versus uec_priv, so I'd like to just add a phydev member to struct uec_priv, remove struct qe_uec_priv, make .priv_auto_alloc_size = sizeof(struct uec_priv), and eliminate the malloc/free pair in .prove/.remove. It's mostly mechanical using coccinelle, but WDYT? Sounds good, so please send a patch... thanks! bye, Heiko Rasmus Villemoes (3): mdio-uclass.c: support fixed-link subnodes dm_qe_uec.c: fix indentation in uec_set_mac_if_mode() uec.h: fix COFIG_DM typo drivers/net/qe/dm_qe_uec.c | 4 ++-- drivers/net/qe/uec.h | 2 +- net/mdio-uclass.c | 7 +++ 3 files changed, 10 insertions(+), 3 deletions(-) -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 2/3] dm_qe_uec.c: fix indentation in uec_set_mac_if_mode()
Hello Rasmus,
Am 05.10.2020 um 15:15 schrieb Rasmus Villemoes:
Signed-off-by: Rasmus Villemoes
---
drivers/net/qe/dm_qe_uec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qe/dm_qe_uec.c b/drivers/net/qe/dm_qe_uec.c
index 3482b3ff17..e2b8bf02f9 100644
--- a/drivers/net/qe/dm_qe_uec.c
+++ b/drivers/net/qe/dm_qe_uec.c
@@ -171,8 +171,8 @@ static int uec_set_mac_if_mode(struct uec_priv *uec)
break;
default:
return -EINVAL;
- }
- break;
+ }
+ break;
case SPEED_1000:
maccfg2 |= MACCFG2_INTERFACE_MODE_BYTE;
switch (enet_if_mode) {
Thanks!
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 3/3] uec.h: fix COFIG_DM typo
Hello Rasmus,
Am 05.10.2020 um 15:15 schrieb Rasmus Villemoes:
Signed-off-by: Rasmus Villemoes
---
drivers/net/qe/uec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/qe/uec.h b/drivers/net/qe/uec.h
index 7cd4b8737a..32b7d3e561 100644
--- a/drivers/net/qe/uec.h
+++ b/drivers/net/qe/uec.h
@@ -678,7 +678,7 @@ struct uec_priv {
int grace_stopped_tx;
int grace_stopped_rx;
int the_first_run;
-#if !defined(COFIG_DM)
+#if !defined(CONFIG_DM)
/* PHY specific */
struct uec_mii_info *mii_info;
int oldspeed;
Ouch... Thanks for detecting this!
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 1/3] mdio-uclass.c: support fixed-link subnodes
Hello Rasmus,
Am 05.10.2020 um 15:15 schrieb Rasmus Villemoes:
When trying to port our mpc8309-based board to DM_ETH, on top of
Heiko's patches, I found that nothing in mdio-uclass.c seems to
support the use of a fixed-link subnode of the ethernet DT node. That
is, the ethernet node looks like
enet0: ethernet@2000 {
device_type = "network";
compatible = "ucc_geth";
...
fixed-link {
reg = <0x>;
speed = <100>;
full-duplex;
};
but the current code expects there to be phy-handle property. Adding
that, i.e.
phy-handle = <&enet0phy>;
enet0phy: fixed-link {
just makes the code break a few lines later since a fixed-link node
doesn't have a reg property. Ignoring the dtc complaint and adding a
dummy reg property, we of course hit "can't find MDIO bus for node
ethernet@2000" since indeed, the parent node of the phy node does not
represent an MDIO bus. So that's obviously the wrong path.
Now, in linux, it seems that the fixed link case is treated specially;
in the of_phy_get_and_connect() which roughly corresponds to
dm_eth_connect_phy_handle() we have
if (of_phy_is_fixed_link(np)) {
ret = of_phy_register_fixed_link(np);
...
} else {
phy_np = of_parse_phandle(np, "phy-handle", 0);
...
}
phy = of_phy_connect(dev, phy_np, hndlr, 0, iface);
And U-Boot's phy_connect() does have support for fixed-link
subnodes. Calling phy_connect() directly with NULL bus and a dummy
address does seem to make the ethernet work.
Signed-off-by: Rasmus Villemoes
---
net/mdio-uclass.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 66ee2e1976..2f932b77df 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -139,6 +139,12 @@ static struct phy_device *dm_eth_connect_phy_handle(struct
udevice *ethdev,
struct ofnode_phandle_args phandle = {.node = ofnode_null()};
int i;
+ if (CONFIG_IS_ENABLED(PHY_FIXED) &&
+ ofnode_valid(dev_read_subnode(ethdev, "fixed-link"))) {
+ phy = phy_connect(NULL, -1, ethdev, interface);
+ goto out;
+ }
+
for (i = 0; i < PHY_HANDLE_STR_CNT; i++)
if (!dev_read_phandle_with_args(ethdev, phy_handle_str[i], NULL,
0, 0, &phandle))
@@ -168,6 +174,7 @@ static struct phy_device *dm_eth_connect_phy_handle(struct
udevice *ethdev,
phy = dm_mdio_phy_connect(mdiodev, phy_addr, ethdev, interface);
+out:
if (phy)
phy->node = phandle.node;
Looks good to me... but I am not an expert in net subsystem...
nevertheless:
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 3/5] bloblist: Tidy up the data alignment
On 20/09/2020 02.49, Simon Glass wrote: > The intention which bloblists is that each blob's data is aligned in > memory. At present it is only the headers that are aligned. > > Update the code to correct this and add a little more documentation. Hi Simon I haven't read this patch in detail, but I have a general request regarding changes to the bloblist layout: Backwards compatibility - in the sense that, if the bloblist is generated by SPL from 2020.04, that should also be usable from a U-Boot proper as of 2021.01 etc. While I/we don't actually use bloblist currently, we have some ideas for what we might use it for on various boards. But, on at least one board, our SPL is stored in read-only storage after production, while we have redundant (and updatable) copies of U-Boot proper - so it's important that a future U-Boot can also grok a bloblist generated by earlier code. Is that guaranteed? Thanks, Rasmus
Re: Fit images and EFI_LOAD_FILE2_PROTOCOL
Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely :
>
>
>On 03/10/2020 09:51, Heinrich Schuchardt wrote:
>> Hello Ilias, hello Christian,
>>
>> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
>initramfs
>> loading") Ilias provided the possibility to specify a device path
>> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
>> served via the EFI_FILE_LOAD2_PROTOCOL.
>>
>> Ard extended the Linux EFI stub to allow loading the initial RAM disk
>> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
>>
>> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
>> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
>> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
>>
>> In the DTE calls we have discussed that it is unfortunate that we do
>not
>> have a method to validate initial RAM images in the UEFI context.
>>
>> To me it would look like a good path forward to combine the two
>ideas:
>>
>> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
>> * Pass location and size to the UEFI subsystem and serve them via
>>the EFI_FILE_LOAD2_PROTOCOL.
>>
>> We could also extend the bootefi command to be callable as
>>
>> bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
>>
>> like the booti command to serve an initial RAM disk.
>>
>> What are your thoughts?
>
>Hi Heinrich,
>
>I've got concerns about this approach. Even though it uses the UEFI
>infrastructure, images deployed in this way are U-Boot specific and
>won't ever be applicable on EDK2 or other UEFI implementations.
>
>However there is another way to approach it which I think Francois
>touched on. If instead a UEFI stub was added to the FIT image, in the
>same way that the kernel has a UEFI stub, then the logic of decoding
>the
>FIT and choosing the correct DTB & initrd can be part of the image and
>it becomes applicable to any UEFI implementation. It would also address
>
>Ard's concern of loading the FIT into memory, and then copying due to
>the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
>in
>RAM, that is is reserved correctly, and just pass the correct addresses
>
>to the kernel as part of the normal boot flow.
>
>Signing would also be taken care of because the whole FIT can be
>signed,
>and that signature would be checked when it gets loaded.
>
>Thoughts?
>
The gain of a fit image in U-Boot used for calling the Linux kernel via the EFI
stub vs calling the legacy entry point comes down to providing the
EFI_RNG_PROTOCOL to be used for KASLR.
For initrd a stub UEFI binary will work. But if you want to provide a kernel
specific dtb with the same stub binary it will require a new service for
device-tree fixups.
Both approaches are on Francois' DTE slidedeck.
When thinking of security what really is unclear to me is how we can safely
provide the decryption key for the root partition. Without such a means secure
boot stops being secure once Linux starts the init process. I would assume that
only the secure world can provide the key.
Best regards
Heinrich
[PATCH v3] usb: dwc2: Fix control OUT transfer issue
In buffer DMA mode, gadget should re-configure EP 0 to received SETUP
packets when doeptsiz.xfersize is equal to a setup packet size(8 bytes)
and EP 0 is in WAIT_FOR_SETUP state.
Since EP 0 is not enabled in WAIT_FOR_SETUP state, SETUP packets is NOT
received from RxFifo and wriiten to the external memory.
Signed-off-by: Chance.Yang
---
Changes for v2:
- fixed 'cast from pointer to integer of different size'
Changes for v3:
- fixed the typo on subject
- remove the unnecessary extra braces
---
drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index 1c0505eb28..f17009a29e 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -421,6 +421,9 @@ static void process_ep_out_intr(struct dwc2_udc *dev)
{
u32 ep_intr, ep_intr_status;
u8 ep_num = 0;
+ u32 ep_tsr = 0, xfer_size = 0;
+ u32 epsiz_reg = reg->out_endp[ep_num].doeptsiz;
+ u32 req_size = sizeof(struct usb_ctrlrequest);
ep_intr = readl(®->daint);
debug_cond(DEBUG_OUT_EP != 0,
@@ -441,10 +444,17 @@ static void process_ep_out_intr(struct dwc2_udc *dev)
if (ep_num == 0) {
if (ep_intr_status & TRANSFER_DONE) {
- if (dev->ep0state !=
- WAIT_FOR_OUT_COMPLETE)
+ ep_tsr = readl(&epsiz_reg);
+ xfer_size = ep_tsr &
+ DOEPT_SIZ_XFER_SIZE_MAX_EP0;
+
+ if (xfer_size == req_size &&
+ dev->ep0state == WAIT_FOR_SETUP) {
+ dwc2_udc_pre_setup();
+ } else if (dev->ep0state !=
+ WAIT_FOR_OUT_COMPLETE) {
complete_rx(dev, ep_num);
- else {
+ } else {
dev->ep0state = WAIT_FOR_SETUP;
dwc2_udc_pre_setup();
}
--
2.17.1
Re: [PATCH v2 1/5] i2c: mediatek: add basic driver support
Hi Mingming,
On Wed, 30 Sep 2020 at 02:22, mingming lee wrote:
>
> From: Mingming Lee
>
> Add MediaTek I2C basic driver
>
> Signed-off-by: Mingming Lee
>
> ---
> Changes for v2:
>- using error number defined in include/linux/errno.h
> ---
> drivers/i2c/Kconfig | 9 +
> drivers/i2c/Makefile | 1 +
> drivers/i2c/mt_i2c.c | 617 +++
> 3 files changed, 627 insertions(+)
> create mode 100644 drivers/i2c/mt_i2c.c
This looks good to me. Some nits below.
>
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index dec6dc9dfa..103688ed36 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -159,6 +159,15 @@ config SYS_I2C_MESON
> internal buffer holding up to 8 bytes for transfers and supports
> both 7-bit and 10-bit addresses.
>
> +config SYS_I2C_MTK
> + bool "MediaTek I2C driver"
> + default n
Not needed
> + help
> + This selects the MediaTek Integrated Inter Circuit bus driver.
> + The I2C bus adapter is the base for some other I2C client, eg:
> touch, sensors.
> + If you want to use MediaTek I2C interface, say Y here.
> + If unsure, say N.
> +
> config SYS_I2C_MXC
> bool "NXP MXC I2C driver"
> help
> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
> index e851ec462e..7227742f8d 100644
> --- a/drivers/i2c/Makefile
> +++ b/drivers/i2c/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_SYS_I2C_LPC32XX) += lpc32xx_i2c.o
> obj-$(CONFIG_SYS_I2C_MESON) += meson_i2c.o
> obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
> obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
> +obj-$(CONFIG_SYS_I2C_MTK) += mt_i2c.o
> obj-$(CONFIG_SYS_I2C_NEXELL) += nx_i2c.o
> obj-$(CONFIG_SYS_I2C_OCTEON) += octeon_i2c.o
> obj-$(CONFIG_SYS_I2C_OMAP24XX) += omap24xx_i2c.o
> diff --git a/drivers/i2c/mt_i2c.c b/drivers/i2c/mt_i2c.c
> new file mode 100644
> index 00..be6262d3d2
> --- /dev/null
> +++ b/drivers/i2c/mt_i2c.c
> @@ -0,0 +1,617 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek I2C Interface driver
> + *
> + * Copyright (C) 2020 MediaTek Inc.
> + * Author: Mingming Lee
> + */
> +
> +#include
> +#include
Check the include-file ordering here:
https://www.denx.de/wiki/U-Boot/CodingStyle
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define I2C_OK 0
Drop this and just use 0
> +
> +#define I2C_RS_TRANSFERBIT(4)
> +#define I2C_HS_NACKERR BIT(2)
> +#define I2C_ACKERR BIT(1)
> +#define I2C_TRANSAC_COMP BIT(0)
> +#define I2C_TRANSAC_START BIT(0)
> +#define I2C_RS_MUL_CNFGBIT(15)
> +#define I2C_RS_MUL_TRIGBIT(14)
> +#define I2C_DCM_DISABLE0x
> +#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003
> +#define I2C_IO_CONFIG_PUSH_PULL0x
> +#define I2C_SOFT_RST 0x0001
> +#define I2C_FIFO_ADDR_CLR 0x0001
> +#define I2C_DELAY_LEN 0x0002
> +#define I2C_ST_START_CON 0x8001
> +#define I2C_FS_START_CON 0x1800
> +#define I2C_TIME_CLR_VALUE 0x
> +#define I2C_TIME_DEFAULT_VALUE 0x0003
> +#define I2C_WRRD_TRANAC_VALUE 0x0002
> +#define I2C_RD_TRANAC_VALUE0x0001
> +
> +#define I2C_DMA_CON_TX 0x
> +#define I2C_DMA_CON_RX 0x0001
> +#define I2C_DMA_START_EN 0x0001
> +#define I2C_DMA_INT_FLAG_NONE 0x
> +#define I2C_DMA_CLR_FLAG 0x
> +#define I2C_DMA_HARD_RST 0x0002
> +
> +#define MAX_ST_MODE_SPEED 10
> +#define MAX_FS_MODE_SPEED 40
> +#define MAX_HS_MODE_SPEED 340
> +#define MAX_SAMPLE_CNT_DIV 8
> +#define MAX_STEP_CNT_DIV 64
> +#define MAX_HS_STEP_CNT_DIV8
> +#define I2C_DEFAULT_CLK_DIV4
> +
> +#define MAX_I2C_ADDR 0x7F
> +#define MAX_I2C_LEN0xFF
Can you use lower-case hex?
> +#define TRANS_ADDR_ONLYBIT(8)
> +#define TRANSFER_TIMEOUT 5 /* us */
> +#define I2C_FIFO_STAT1_MASK0x001F
> +#define TIMING_SAMPLE_OFFSET 8
> +#define HS_SAMPLE_OFFSET 12
> +#define HS_STEP_OFFSET 8
> +
> +#define I2C_CONTROL_WRAPPERBIT(0)
> +#define I2C_CONTROL_RS BIT(1)
> +#define I2C_CONTROL_DMA_EN BIT(2)
> +#define I2C_CONTROL_CLK_EXT_EN BIT(3)
> +#define I2C_CONTROL_DIR_CHANGE BIT(4)
> +#define I2C_CONTROL_ACKERR_DET_EN BIT(5)
> +#define I2C_CONTROL_TRANSFER_LEN_CHANGE BIT(6)
> +#define I2C_CONTROL_DMAACK BIT(8)
> +#define I2C_CONTROL_ASYNC BIT(9)
> +
> +enum I2C_REGS_OFFSET {
> + OFFSET_PORT = 0x0,
> + OFFSET_SLAVE_ADDR = 0x04,
> + OFFSET_INTR_MASK = 0x08,
> + OFFSET_INTR_STAT = 0x0C,
> + OFFSET_CONTROL = 0x10,
> + OFF
Re: Fit images and EFI_LOAD_FILE2_PROTOCOL
On 03/10/2020 09:51, Heinrich Schuchardt wrote:
Hello Ilias, hello Christian,
with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for initramfs
loading") Ilias provided the possibility to specify a device path
(CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
served via the EFI_FILE_LOAD2_PROTOCOL.
Ard extended the Linux EFI stub to allow loading the initial RAM disk
via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
IH_OS_EFI") Cristian enabled signed FIT images that contain a device
tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
In the DTE calls we have discussed that it is unfortunate that we do not
have a method to validate initial RAM images in the UEFI context.
To me it would look like a good path forward to combine the two ideas:
* Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
* Pass location and size to the UEFI subsystem and serve them via
the EFI_FILE_LOAD2_PROTOCOL.
We could also extend the bootefi command to be callable as
bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
like the booti command to serve an initial RAM disk.
What are your thoughts?
Hi Heinrich,
I've got concerns about this approach. Even though it uses the UEFI
infrastructure, images deployed in this way are U-Boot specific and
won't ever be applicable on EDK2 or other UEFI implementations.
However there is another way to approach it which I think Francois
touched on. If instead a UEFI stub was added to the FIT image, in the
same way that the kernel has a UEFI stub, then the logic of decoding the
FIT and choosing the correct DTB & initrd can be part of the image and
it becomes applicable to any UEFI implementation. It would also address
Ard's concern of loading the FIT into memory, and then copying due to
the EFI_FILE_LOAD2 path. The FIT stub would already know the image is in
RAM, that is is reserved correctly, and just pass the correct addresses
to the kernel as part of the normal boot flow.
Signing would also be taken care of because the whole FIT can be signed,
and that signature would be checked when it gets loaded.
Thoughts?
g.
Re: [PATCH 15/17] pytest: Collect SPL unit tests
On 10/5/20 1:51 PM, Simon Glass wrote:
> Hi Stephen,
>
> On Mon, 5 Oct 2020 at 13:39, Stephen Warren wrote:
>>
>> On 10/3/20 9:25 AM, Simon Glass wrote:
>>> Add a new test_spl fixture to handle running SPL unit tests.
>>
>>> diff --git a/test/py/conftest.py b/test/py/conftest.py
>>
>>> @@ -317,10 +318,13 @@ def pytest_generate_tests(metafunc):
>>> Returns:
>>> Nothing.
>>> """
>>> -
>>> +#print('name', metafunc.fixturenames)
>>
>> Revert that debug change?
>
> Will do.
>
>>
>>> diff --git a/test/py/tests/test_spl.py b/test/py/tests/test_spl.py
>>
>>> +cons.restart_uboot_with_flags(['-u', ut_spl_subtest])
>>
>> How is that change reverted when the test runs, so that subsequent tests
>> are run on the main U-Boot rather than this restarted U-Boot?
>
> Well actually at the moment it just continues into U-Boot. It will
> mostly pass the tests, but probably not all of them.
Looking at existing tests, there are quite a few that do this:
try:
test body which might do something nasty to U-Boot
finally:
u_boot_console.restart_uboot()
... so that might be applicable.
>> It feels like it'd be better to start a separate top-level test run for
>> this purpose, rather than swap out the U-Boot process in the middle of a
>> test run.
>
> I was hoping that the fixture stuff would take care of that. How would
> I do a separate top-level test run?
That'd simply be just running test/py/test.py and passing it the
relevant U-Boot binary/args rather than the main binary. I assume you'd
want to pass relevant -k option to restrict the set of tests run to
something relevant, and an appropriate --build-dir option to point at
the binary.
Re: [PATCH] dm: ofnode: Fix compile breakage with OF_CHECKS enabled
Hi Stefan, On Wed, 23 Sep 2020 at 00:23, Stefan Roese wrote: > > Include missing log.h and change _ofnode_to_np() to ofnode_to_np() so > that compiling with OF_CHECKS enabled does not break. > > Signed-off-by: Stefan Roese > Cc: Simon Glass > --- > include/dm/ofnode.h | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass We need to find a way to test this, perhaps by enabling it on one of the sandbox builds and calling a few functions with invalid data. Regards, SImon Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/5] bloblist: Add a command
It is helpful to be able to see basic statistics about the bloblist and also to list its contents. Add a 'bloblist' command to handle this. Put the display functions in the bloblist modules rather than in the command code itself. That allows showing a list from SPL, where commands are not available. Also make bloblist_first/next_blob() static as they are not used outside this file. Signed-off-by: Simon Glass --- cmd/Kconfig| 9 +++ cmd/Makefile | 1 + cmd/bloblist.c | 37 +++ common/bloblist.c | 62 +++--- include/bloblist.h | 32 test/bloblist.c| 59 ++- 6 files changed, 196 insertions(+), 4 deletions(-) create mode 100644 cmd/bloblist.c Applied to u-boot-dm/next, thanks!
Re: [PATCH 2/5] bloblist: Compare addresses rather than pointers in tests
When running these tests on sandbox any failures result in very large or long pointer values which are a pain to work with. Map them to an address so it is easier to diagnose failures. Signed-off-by: Simon Glass --- include/test/ut.h | 13 + test/bloblist.c | 17 + 2 files changed, 22 insertions(+), 8 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] doc/arch/sandbox.rst: reformat command line options
On Sat, 19 Sep 2020 at 12:05, Heinrich Schuchardt wrote: > > Reformat the command line options chapter so that the command line options > clearly stand out. > > Signed-off-by: Heinrich Schuchardt > --- > doc/arch/sandbox.rst | 57 +--- > 1 file changed, 33 insertions(+), 24 deletions(-) > Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] MAINTAINERS: assign doc/arch/sandbox.rst
On Sat, 19 Sep 2020 at 12:05, Heinrich Schuchardt wrote: > > Add doc/arch/sandbox.rst to the scope of SANDBOX. > > Signed-off-by: Heinrich Schuchardt > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 3/5] bloblist: Tidy up the data alignment
The intention which bloblists is that each blob's data is aligned in memory. At present it is only the headers that are aligned. Update the code to correct this and add a little more documentation. Signed-off-by: Simon Glass --- common/bloblist.c | 32 ++-- test/bloblist.c | 38 +- 2 files changed, 63 insertions(+), 7 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 4/5] bloblist: Allow custom alignment for blobs
Some blobs need a larger alignment than the default. For example, ACPI tables often start at a 4KB boundary. Add support for this. Update the size of the test blob to allow these larger records. Signed-off-by: Simon Glass --- common/bloblist.c | 32 include/bloblist.h | 6 -- test/bloblist.c| 42 +- 3 files changed, 57 insertions(+), 23 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 5/5] bloblist: Fix up a few comments
Adjust a few comments to make the meaning clearer. Signed-off-by: Simon Glass --- include/bloblist.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH] dm: update test on of_offset in ofnode_valid
On Thu, 24 Sep 2020 at 09:26, Patrick Delaunay wrote: > > Update the test for node.of_offset because an invalid offset is not > always set to -1 because the return value of the libfdt functions are: > + an error with a value < 0 > + a valid offset with value >=0 > > For example, in ofnode_get_by_phandle() function, we have: > node.of_offset = fdt_node_offset_by_phandle(gd->fdt_blob, phandle); > and this function can return -FDT_ERR_BADPHANDLE (-6). > > Without this patch, the added test dm_test_ofnode_get_by_phandle failed. > > Signed-off-by: Patrick Delaunay > --- > > include/dm/ofnode.h | 2 +- > test/dm/ofnode.c| 16 > 2 files changed, 17 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 2/3] fdtdec: correct test on return of fdt_node_offset_by_phandle
On Fri, 25 Sep 2020 at 01:41, Patrick Delaunay wrote: > > The result of fdt_node_offset_by_phandle is negative for error, > so this patch corrects the check of this result in > fdtdec_parse_phandle_with_args. > > This patch allows to have the same behavior with or without OF_LIVE > for the function dev_read_phandle_with_args with cell_name = NULL and > with invalid phandle. > > Signed-off-by: Patrick Delaunay > --- > > lib/fdtdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] sandbox: add missing SDL key scan codes
On Mon, 28 Sep 2020 at 17:41, Heinrich Schuchardt wrote: > > Add missing SDL key scan codes, e.g. > > * shift, ctrl, meta, alt > * brace/bracket > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/sdl.c | 156 +++-- > 1 file changed, 89 insertions(+), 67 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] sandbox: avoid duplicate backslash input
On Mon, 28 Sep 2020 at 19:56, Heinrich Schuchardt wrote: > > When using SDL for input the SDL key codes are first converted to Linux key > codes and then to matrix entries of the cross wired keyboard. > > We must not map any key code to two different places on the keyboard. So > comment out one backslash position. > > Update the rest of the file from Linux 5.7. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/dts/cros-ec-keyboard.dtsi | 20 +++- > 1 file changed, 15 insertions(+), 5 deletions(-) > Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 3/3] test: dm: add test for phandle access functions
On Fri, 25 Sep 2020 at 01:41, Patrick Delaunay wrote: > > Add unitary test for phandle access functions > - ofnode_count_phandle_with_args > - ofnode_parse_phandle_with_args > - dev_count_phandle_with_args > - dev_read_phandle_with_args > > Signed-off-by: Patrick Delaunay > --- > > arch/sandbox/dts/test.dts | 1 + > test/dm/ofnode.c | 75 +++ > test/dm/test-fdt.c| 65 + > 3 files changed, 141 insertions(+) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
"next" now merged to master
Hey all, I've now merged the "next" branch back in to "master". There was one call fdtdec_add_reserved_memory() that I had to update to pass in the new default final arg of "false". -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] usb: dwc2: Fix contorl OUT transfer issue
On 10/5/20 9:11 AM, Chance.Yang wrote:
Please fix the "contorl" typo on subject, should be "control"
[...]
> @@ -441,10 +444,17 @@ static void process_ep_out_intr(struct dwc2_udc *dev)
>
> if (ep_num == 0) {
> if (ep_intr_status & TRANSFER_DONE) {
> - if (dev->ep0state !=
> - WAIT_FOR_OUT_COMPLETE)
> + ep_tsr = readl(&epsiz_reg);
> + xfer_size = (ep_tsr &
> +DOEPT_SIZ_XFER_SIZE_MAX_EP0);
The extra braces are not needed, please drop them.
Thanks
Re: [PATCH 15/17] pytest: Collect SPL unit tests
Hi Stephen,
On Mon, 5 Oct 2020 at 13:39, Stephen Warren wrote:
>
> On 10/3/20 9:25 AM, Simon Glass wrote:
> > Add a new test_spl fixture to handle running SPL unit tests.
>
> > diff --git a/test/py/conftest.py b/test/py/conftest.py
>
> > @@ -317,10 +318,13 @@ def pytest_generate_tests(metafunc):
> > Returns:
> > Nothing.
> > """
> > -
> > +#print('name', metafunc.fixturenames)
>
> Revert that debug change?
Will do.
>
> > diff --git a/test/py/tests/test_spl.py b/test/py/tests/test_spl.py
>
> > +cons.restart_uboot_with_flags(['-u', ut_spl_subtest])
>
> How is that change reverted when the test runs, so that subsequent tests
> are run on the main U-Boot rather than this restarted U-Boot?
Well actually at the moment it just continues into U-Boot. It will
mostly pass the tests, but probably not all of them.
>
> It feels like it'd be better to start a separate top-level test run for
> this purpose, rather than swap out the U-Boot process in the middle of a
> test run.
I was hoping that the fixture stuff would take care of that. How would
I do a separate top-level test run?
Regards,
Simon
Re: [PATCH 15/17] pytest: Collect SPL unit tests
On 10/3/20 9:25 AM, Simon Glass wrote:
> Add a new test_spl fixture to handle running SPL unit tests.
> diff --git a/test/py/conftest.py b/test/py/conftest.py
> @@ -317,10 +318,13 @@ def pytest_generate_tests(metafunc):
> Returns:
> Nothing.
> """
> -
> +#print('name', metafunc.fixturenames)
Revert that debug change?
> diff --git a/test/py/tests/test_spl.py b/test/py/tests/test_spl.py
> +cons.restart_uboot_with_flags(['-u', ut_spl_subtest])
How is that change reverted when the test runs, so that subsequent tests
are run on the main U-Boot rather than this restarted U-Boot?
It feels like it'd be better to start a separate top-level test run for
this purpose, rather than swap out the U-Boot process in the middle of a
test run.
[PATCH 7/7] configs: sam9x60ek: update defconfigs for CCF
Update defconfigs for using common clock framework compatible clocks. Signed-off-by: Claudiu Beznea --- configs/sam9x60ek_mmc_defconfig | 4 +++- configs/sam9x60ek_nandflash_defconfig | 4 +++- configs/sam9x60ek_qspiflash_defconfig | 4 +++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/configs/sam9x60ek_mmc_defconfig b/configs/sam9x60ek_mmc_defconfig index 2600f4d79d46..4afa8856ef69 100644 --- a/configs/sam9x60ek_mmc_defconfig +++ b/configs/sam9x60ek_mmc_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_AT91=y CONFIG_SYS_TEXT_BASE=0x23f0 CONFIG_TARGET_SAM9X60EK=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x4000 CONFIG_DM_GPIO=y @@ -36,8 +36,10 @@ CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_CLK=y +CONFIG_CLK_CCF=y CONFIG_CLK_AT91=y CONFIG_AT91_GENERIC_CLK=y +CONFIG_AT91_SAM9X60_PLL=y CONFIG_AT91_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_AT91=y diff --git a/configs/sam9x60ek_nandflash_defconfig b/configs/sam9x60ek_nandflash_defconfig index e21efff34208..481356140966 100644 --- a/configs/sam9x60ek_nandflash_defconfig +++ b/configs/sam9x60ek_nandflash_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_AT91=y CONFIG_SYS_TEXT_BASE=0x23f0 CONFIG_TARGET_SAM9X60EK=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_NR_DRAM_BANKS=8 CONFIG_DM_GPIO=y CONFIG_DEBUG_UART_BOARD_INIT=y @@ -40,8 +40,10 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_CLK=y +CONFIG_CLK_CCF=y CONFIG_CLK_AT91=y CONFIG_AT91_GENERIC_CLK=y +CONFIG_AT91_SAM9X60_PLL=y CONFIG_AT91_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_AT91=y diff --git a/configs/sam9x60ek_qspiflash_defconfig b/configs/sam9x60ek_qspiflash_defconfig index 1123ebcd5250..16852da810e8 100644 --- a/configs/sam9x60ek_qspiflash_defconfig +++ b/configs/sam9x60ek_qspiflash_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_AT91=y CONFIG_SYS_TEXT_BASE=0x23f0 CONFIG_TARGET_SAM9X60EK=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_DM_GPIO=y @@ -48,8 +48,10 @@ CONFIG_ENV_SPI_MODE=0x0 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_CLK=y +CONFIG_CLK_CCF=y CONFIG_CLK_AT91=y CONFIG_AT91_GENERIC_CLK=y +CONFIG_AT91_SAM9X60_PLL=y CONFIG_AT91_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_AT91=y -- 2.7.4
[PATCH 6/7] ARM: dts: sam9x60: use CCF compatibles for PMC
Use CCF compatible for PMC. With this, the board/SoC will be
able to boot.
Signed-off-by: Claudiu Beznea
---
arch/arm/dts/sam9x60.dtsi | 135 -
arch/arm/dts/sam9x60ek-u-boot.dtsi | 52 --
arch/arm/dts/sam9x60ek.dts | 2 +-
3 files changed, 28 insertions(+), 161 deletions(-)
diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 7210647893ee..79a0417928f5 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
/{
model = "Microchip SAM9X60 SoC";
@@ -34,6 +34,13 @@
u-boot,dm-pre-reloc;
};
+ main_rc: main_rc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1200>;
+ u-boot,dm-pre-reloc;
+ };
+
slow_xtal: slow_xtal {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -56,8 +63,11 @@
sdhci0: sdhci-host@8000 {
compatible = "microchip,sam9x60-sdhci";
reg = <0x8000 0x300>;
- clocks = <&sdhci0_clk>, <&sdhci0_gclk>, <&main>;
- clock-names = "hclock", "multclk", "baseclk";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 12>, <&pmc
PMC_TYPE_GCK 12>;
+ clock-names = "hclock", "multclk";
+ assigned-clocks = <&pmc PMC_TYPE_GCK 12>;
+ assigned-clock-rates = <1>;
+ assigned-clock-parents = <&pmc PMC_TYPE_CORE 10>; /*
ID_PLL_A_DIV */
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sdhci0>;
@@ -73,7 +83,7 @@
compatible = "microchip,sam9x60-qspi";
reg = <0xf0014000 0x100>, <0x7000
0x1000>;
reg-names = "qspi_base", "qspi_mmap";
- clocks = <&qspi_clk>, <&qspick>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 35>, <&pmc
PMC_TYPE_SYSTEM 18>; /* ID_QSPI */
clock-names = "pclk", "qspick";
#address-cells = <1>;
#size-cells = <0>;
@@ -83,7 +93,7 @@
flx0: flexcom@f801c600 {
compatible = "atmel,sama5d2-flexcom";
reg = <0xf801c000 0x200>;
- clocks = <&flx0_clk>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 5>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xf801c000 0x800>;
@@ -96,7 +106,7 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_macb0_rmii>;
clock-names = "hclk", "pclk";
- clocks = <&macb0_clk>, <&macb0_clk>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 24>, <&pmc
PMC_TYPE_PERIPHERAL 24>;
status = "disabled";
};
@@ -105,7 +115,7 @@
reg = <0xf200 0x200>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dbgu>;
- clocks = <&dbgu_clk>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 47>;
clock-names = "usart";
};
@@ -162,7 +172,7 @@
reg = <0xf400 0x200>;
#gpio-cells = <2>;
gpio-controller;
- clocks = <&pioA_clk>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 2>;
};
pioB: gpio@f600 {
@@ -170,7 +180,7 @@
reg = <0xf600 0x200>;
#gpio-cells = <2>;
gpio-controller;
- clocks = <&pioB_clk>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 3>;
};
pioD: gpio@fa00 {
@@ -178,114 +188,23 @@
reg = <0xfa00 0x200>;
#gpio-cells = <2>;
gpio-controller;
- clocks = <&pioD_clk>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 44>;
};
[PATCH 5/7] ARM: dts: sam9x60: use slow clock CCF compatible bindings
Use slow clock CCF compatible DT bindings. This will not break
the above functionality as the SoC is not booting with current
PMC bindings.
Signed-off-by: Claudiu Beznea
---
arch/arm/dts/sam9x60.dtsi | 42 +-
arch/arm/dts/sam9x60ek-u-boot.dtsi | 17 +--
2 files changed, 15 insertions(+), 44 deletions(-)
diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index a4e2576d8e0f..7210647893ee 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -27,6 +27,13 @@
};
clocks {
+ slow_rc_osc: slow_rc_osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ u-boot,dm-pre-reloc;
+ };
+
slow_xtal: slow_xtal {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -198,7 +205,7 @@
mck: masterck {
compatible =
"atmel,at91sam9x5-clk-master";
#clock-cells = <0>;
- clocks = <&md_slck>, <&main>, <&plla>;
+ clocks = <&clk32 0>, <&main>, <&plla>;
atmel,clk-output-range = <14000
2>;
atmel,clk-divisors = <1 2 4 6>;
};
@@ -266,7 +273,7 @@
compatible =
"microchip,sam9x60-clk-generated";
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&md_slck>, <&td_slck>,
<&main>, <&mck>, <&plla>;
+ clocks = <&clk32 0>, <&clk32 1>,
<&main>, <&mck>, <&plla>;
sdhci0_gclk: sdhci0_gclk {
#clock-cells = <0>;
@@ -281,33 +288,12 @@
clocks = <&mck>;
};
- slowckc: sckc@fe50 {
- compatible = "atmel,at91sam9x5-sckc";
+ clk32: sckc@fe50 {
+ compatible = "microchip,sam9x60-sckc";
reg = <0xfe50 0x4>;
-
- slow_osc: slow_osc {
- compatible =
"atmel,at91sam9x5-clk-slow-osc";
- #clock-cells = <0>;
- clocks = <&slow_xtal>;
- };
-
- slow_rc_osc: slow_rc_osc {
- compatible =
"atmel,at91sam9x5-clk-slow-rc-osc";
- #clock-cells = <0>;
- clock-frequency = <32768>;
- };
-
- td_slck: td_slck {
- compatible =
"atmel,at91sam9x5-clk-slow";
- #clock-cells = <0>;
- clocks = <&slow_rc_osc>, <&slow_osc>;
- };
-
- md_slck: md_slck {
- compatible =
"atmel,at91sam9x5-clk-slow";
- #clock-cells = <0>;
- clocks = <&slow_rc_osc>;
- };
+ clocks = <&slow_rc_osc>, <&slow_xtal>;
+ #clock-cells = <1>;
+ u-boot,dm-pre-reloc;
};
};
};
diff --git a/arch/arm/dts/sam9x60ek-u-boot.dtsi
b/arch/arm/dts/sam9x60ek-u-boot.dtsi
index 93cf1262f6fc..f6d387d4fac9 100644
--- a/arch/arm/dts/sam9x60ek-u-boot.dtsi
+++ b/arch/arm/dts/sam9x60ek-u-boot.dtsi
@@ -111,22 +111,7 @@
u-boot,dm-pre-reloc;
};
-&slowckc {
+&clk32 {
u-boot,dm-pre-reloc;
};
-&slow_osc {
- u-boot,dm-pre-reloc;
-};
-
-&slow_rc_osc {
- u-boot,dm-pre-reloc;
-};
-
-&td_slck {
- u-boot,dm-pre-reloc;
-};
-
-&md_slck {
- u-boot,dm-pre-reloc;
-};
--
2.7.4
[PATCH 1/7] board: atmel: sam9x60ek: add SYS_MALLOC_F_LEN to SYS_INIT_SP_ADDR
Heap base address is computed based on SYS_INIT_SP_ADDR by subtracting the SYS_MALLOC_F_LEN value in board_init_f_init_reserve(). Signed-off-by: Claudiu Beznea --- include/configs/sam9x60ek.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/sam9x60ek.h b/include/configs/sam9x60ek.h index 19714402ca45..6a6f1de41d1e 100644 --- a/include/configs/sam9x60ek.h +++ b/include/configs/sam9x60ek.h @@ -40,7 +40,8 @@ #define CONFIG_SYS_SDRAM_SIZE 0x1000 /* 256 megs */ #define CONFIG_SYS_INIT_SP_ADDR \ - (CONFIG_SYS_SDRAM_BASE + 16 * 1024 - GENERATED_GBL_DATA_SIZE) + (CONFIG_SYS_SDRAM_BASE + 16 * 1024 + CONFIG_SYS_MALLOC_F_LEN - \ +GENERATED_GBL_DATA_SIZE) /* NAND flash */ #ifdef CONFIG_CMD_NAND -- 2.7.4
[PATCH 3/7] ARM: dts: sam9x60ek: add clock frequencies to board file
Slow Xtal and Main Xtal are board specific. Add their proper
frequency to board file.
Signed-off-by: Claudiu Beznea
---
arch/arm/dts/sam9x60.dtsi | 2 --
arch/arm/dts/sam9x60ek.dts | 10 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 41ac1f164c86..51de586e1900 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -30,13 +30,11 @@
slow_xtal: slow_xtal {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <0>;
};
main_xtal: main_xtal {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <0>;
};
};
diff --git a/arch/arm/dts/sam9x60ek.dts b/arch/arm/dts/sam9x60ek.dts
index 8767de98b8dd..44af5d99ee4c 100644
--- a/arch/arm/dts/sam9x60ek.dts
+++ b/arch/arm/dts/sam9x60ek.dts
@@ -18,6 +18,16 @@
i2c0 = &flx0;
};
+ clocks {
+ slow_xtal: slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal: main_xtal {
+ clock-frequency = <2400>;
+ };
+ };
+
onewire_tm: onewire {
gpios = <&pioD 14 0>;
pinctrl-names = "default";
--
2.7.4
[PATCH 2/7] clk: at91: sam9x60: add support compatible with CCF
Add SAM9X60 clock support compatible with CCF.
Signed-off-by: Claudiu Beznea
---
drivers/clk/at91/Makefile | 1 +
drivers/clk/at91/sam9x60.c | 594 +
2 files changed, 595 insertions(+)
create mode 100644 drivers/clk/at91/sam9x60.c
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 2453c38af1aa..580b406d7bd6 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_AT91_GENERIC_CLK)+= clk-generic.o
obj-$(CONFIG_AT91_UTMI)+= clk-utmi.o
obj-$(CONFIG_AT91_SAM9X60_PLL) += clk-sam9x60-pll.o
obj-$(CONFIG_SAMA7G5) += sama7g5.o
+obj-$(CONFIG_SAM9X60) += sam9x60.o
else
obj-y += compat.o
endif
diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
new file mode 100644
index ..10ef85fca2cf
--- /dev/null
+++ b/drivers/clk/at91/sam9x60.c
@@ -0,0 +1,594 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudiu Beznea
+ *
+ * Based on sam9x60.c on Linux.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "pmc.h"
+
+/**
+ * Clock identifiers to be used in conjunction with macros like
+ * AT91_TO_CLK_ID()
+ *
+ * @ID_MD_SLCK:TD slow clock identifier
+ * @ID_TD_SLCK:MD slow clock identifier
+ * @ID_MAIN_XTAL: Main Xtal clock identifier
+ * @ID_MAIN_RC:Main RC clock identifier
+ * @ID_MAIN_RC_OSC:Main RC Oscillator clock identifier
+ * @ID_MAIN_OSC: Main Oscillator clock identifier
+ * @ID_MAINCK: MAINCK clock identifier
+ * @ID_PLL_U_FRAC: UPLL fractional clock identifier
+ * @ID_PLL_U_DIV: UPLL divider clock identifier
+ * @ID_PLL_A_FRAC: APLL fractional clock identifier
+ * @ID_PLL_A_DIV: APLL divider clock identifier
+
+ * @ID_MCK:MCK clock identifier
+
+ * @ID_UTMI: UTMI clock identifier
+
+ * @ID_PROG0: Programmable 0 clock identifier
+ * @ID_PROG1: Programmable 1 clock identifier
+
+ * @ID_PCK0: PCK0 system clock identifier
+ * @ID_PCK1: PCK1 system clock identifier
+ * @ID_DDR:DDR system clock identifier
+ * @ID_QSPI: QSPI system clock identifier
+ *
+ * Note: if changing the values of this enums please sync them with
+ * device tree
+ */
+enum pmc_clk_ids {
+ ID_MD_SLCK = 0,
+ ID_TD_SLCK = 1,
+ ID_MAIN_XTAL= 2,
+ ID_MAIN_RC = 3,
+ ID_MAIN_RC_OSC = 4,
+ ID_MAIN_OSC = 5,
+ ID_MAINCK = 6,
+
+ ID_PLL_U_FRAC = 7,
+ ID_PLL_U_DIV= 8,
+ ID_PLL_A_FRAC = 9,
+ ID_PLL_A_DIV= 10,
+
+ ID_MCK = 11,
+
+ ID_UTMI = 12,
+
+ ID_PROG0= 13,
+ ID_PROG1= 14,
+
+ ID_PCK0 = 15,
+ ID_PCK1 = 16,
+
+ ID_DDR = 17,
+ ID_QSPI = 18,
+
+ ID_MAX,
+};
+
+/**
+ * PLL type identifiers
+ * @PLL_TYPE_FRAC: fractional PLL identifier
+ * @PLL_TYPE_DIV: divider PLL identifier
+ */
+enum pll_type {
+ PLL_TYPE_FRAC,
+ PLL_TYPE_DIV,
+};
+
+/* Clock names used as parents for multiple clocks. */
+static const char *clk_names[] = {
+ [ID_MAIN_RC_OSC]= "main_rc_osc",
+ [ID_MAIN_OSC] = "main_osc",
+ [ID_MAINCK] = "mainck",
+ [ID_PLL_U_DIV] = "upll_divpmcck",
+ [ID_PLL_A_DIV] = "plla_divpmcck",
+ [ID_MCK]= "mck",
+};
+
+/* Fractional PLL output range. */
+static const struct clk_range plla_outputs[] = {
+ { .min = 2343750, .max = 12 },
+};
+
+static const struct clk_range upll_outputs[] = {
+ { .min = 3, .max = 5 },
+};
+
+/* PLL characteristics. */
+static const struct clk_pll_characteristics apll_characteristics = {
+ .input = { .min = 1200, .max = 4800 },
+ .num_output = ARRAY_SIZE(plla_outputs),
+ .output = plla_outputs,
+};
+
+static const struct clk_pll_characteristics upll_characteristics = {
+ .input = { .min = 1200, .max = 4800 },
+ .num_output = ARRAY_SIZE(upll_outputs),
+ .output = upll_outputs,
+ .upll = true,
+};
+
+/* Layout for fractional PLLs. */
+static const struct clk_pll_layout pll_layout_frac = {
+ .mul_mask = GENMASK(31, 24),
+ .frac_mask = GENMASK(21, 0),
+ .mul_shift = 24,
+ .frac_shift = 0,
+};
+
+/* Layout for DIV PLLs. */
+static const struct clk_pll_layout pll_layout_div = {
+ .div_mask = GENMASK(7, 0),
+ .e
[PATCH 4/7] ARM: dts: sam9x60: use u-boot,dm-pre-reloc
Use u-boot,dm-pre-reloc for slow xtal and main xtal.
Signed-off-by: Claudiu Beznea
---
arch/arm/dts/sam9x60.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 51de586e1900..a4e2576d8e0f 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -30,11 +30,13 @@
slow_xtal: slow_xtal {
compatible = "fixed-clock";
#clock-cells = <0>;
+ u-boot,dm-pre-reloc;
};
main_xtal: main_xtal {
compatible = "fixed-clock";
#clock-cells = <0>;
+ u-boot,dm-pre-reloc;
};
};
--
2.7.4
[PATCH 0/7] add SAM9X60 clock support
Hi, This series adds SAM9X60 clock support, CCF compatible, so that SAM9X60 based boards (e.g. SAM9X60-EK in this case) to be able to boot with mainline code. This series is based on u-boot-atmel/next. Thank you, Claudiu Beznea Claudiu Beznea (7): board: atmel: sam9x60ek: add SYS_MALLOC_F_LEN to SYS_INIT_SP_ADDR clk: at91: sam9x60: add support compatible with CCF ARM: dts: sam9x60ek: add clock frequencies to board file ARM: dts: sam9x60: use u-boot,dm-pre-reloc ARM: dts: sam9x60: use slow clock CCF compatible bindings ARM: dts: sam9x60: use CCF compatibles for PMC configs: sam9x60ek: update defconfigs for CCF arch/arm/dts/sam9x60.dtsi | 177 +++--- arch/arm/dts/sam9x60ek-u-boot.dtsi| 69 +--- arch/arm/dts/sam9x60ek.dts| 12 +- configs/sam9x60ek_mmc_defconfig | 4 +- configs/sam9x60ek_nandflash_defconfig | 4 +- configs/sam9x60ek_qspiflash_defconfig | 4 +- drivers/clk/at91/Makefile | 1 + drivers/clk/at91/sam9x60.c| 594 ++ include/configs/sam9x60ek.h | 3 +- 9 files changed, 659 insertions(+), 209 deletions(-) create mode 100644 drivers/clk/at91/sam9x60.c -- 2.7.4
Re: [PATCH 0/2] mtd: cfi_mtd: Add DMA support for reads
Hi Stefan On 9/17/20 4:53 PM, Vignesh Raghavendra wrote: > This series adds DMA support to read from memory mapped CFI flashes > > First patch reduces noise from DMA APIs > Second patch adds DMA support for cfi_mtd. > > Tested on J721e that has CFI compliant HyperFlash > > Vignesh Raghavendra (2): > dma: Reduce error level when DMA channel type does not exist > mtd: cfi_mtd: Use DMA for reads > > drivers/dma/dma-uclass.c | 4 ++-- > drivers/mtd/cfi_mtd.c| 4 +++- > 2 files changed, 5 insertions(+), 3 deletions(-) > Do you plan to pick up this series via CFI Flash? Or should I ask Tom to pull it in? Thanks! Regards Vignesh
Re: Fit images and EFI_LOAD_FILE2_PROTOCOL
On Mon, 5 Oct 2020 at 17:25, Daniel Thompson
wrote:
> On Mon, Oct 05, 2020 at 04:12:11PM +0200, François Ozog wrote:
> > The driving idea is that there is an existing bootflow, non UEFI that
> > allows vmlinuz, initrd and DTB to be protected in a single FIT. The
> > trustworthiness of the solution is higher that regular distro on pure
> UEFI
> > systems but does not allow initrd changes as you install stuff. We need
> to
> > keep in mind the use cases: most of the cases are for production devices
> > where updates are not "calculated" in place but rather deployed with
> > various means.
> >
> > I'd like to define two EBBR boot flows:
> > 1) typical distro (with its weakness)
> > 2) typical embedded (as of today, addressing security and mix/match
> > protection)
> >
> > The 1) is described in slide 4 of the deck
> > The 2) is described in slide 5.
>
> It seems these discussion keeps looping back to out-of-band resources.
> If we have to keep referring to out-of-band resources to follow
> discussion can you ensure there is a link to said out-of-band resources
> when citing modifications to them.
>
here it is:
https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?usp=sharing
>
> It's frustrating to have to go rummaging through my mail archives to find
> your doc.
>
>
> Daniel.
>
>
> >
> > The UEFI interface is still OS independent but comes with an additional
> > opportunity: the ESP File System is "merged" with contents of a FIT (kind
> > of overlayfs). This way the content of the FIT can be checked and EFIStub
> > with EFI-LOAD_FILE2 the initrd. The boot will still indirectly point
> to
> > the FIT contained .EFI application, the firmware DTB may be overwritten
> by
> > a FIT DTB.
> >
> > Is this a better scenario to establish 2)?
> >
> > Cheers
> >
> >
> > FF
> >
> > On Sat, 3 Oct 2020 at 15:12, Ard Biesheuvel wrote:
> >
> > >
> > >
> > > On Sat, 3 Oct 2020 at 13:16, François Ozog
> > > wrote:
> > >
> > >>
> > >>
> > >> Le sam. 3 oct. 2020 à 13:14, François Ozog
> a
> > >> écrit :
> > >>
> > >>>
> > >>>
> > >>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt
> a
> > >>> écrit :
> > >>>
> > Hello Ilias, hello Christian,
> >
> >
> >
> > with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
> initramfs
> >
> > loading") Ilias provided the possibility to specify a device path
> >
> > (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
> >
> > served via the EFI_FILE_LOAD2_PROTOCOL.
> >
> >
> >
> > Ard extended the Linux EFI stub to allow loading the initial RAM
> disk
> >
> > via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
> >
> >
> >
> > With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
> >
> > IH_OS_EFI") Cristian enabled signed FIT images that contain a device
> >
> > tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
> >
> >
> >
> > In the DTE calls we have discussed that it is unfortunate that we
> do not
> >
> > have a method to validate initial RAM images in the UEFI context.
> >
> >
> >
> > To me it would look like a good path forward to combine the two
> ideas:
> >
> >
> >
> > * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
> >
> > * Pass location and size to the UEFI subsystem and serve them via
> >
> > the EFI_FILE_LOAD2_PROTOCOL.
> >
> >
> >
> > We could also extend the bootefi command to be callable as
> >
> >
> >
> > bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
> >
> >
> >
> > like the booti command to serve an initial RAM disk.
> >
> >
> >
> > What are your thoughts?
> > >>>
> > >>> that looks super interesting.
> > >>> I propose something (in the latest desk preparing oct 14th) similar
> > >>> except the an efi application boots the FIT.
> > >>> I view UEFI as booting a PE coff and pass a set of config tables.
> Today
> > >>> we have DTB, we could just add Initrd (you command line). Bootefi
> would be
> > >>> responsible to valide the containing FIT before pushing initrd (and
> > >>> dTB?)into the table. It would be the responsibility of the efi stub
> to get
> > >>> the initrd from the config table (GUID to be defined).
> > >>>
> > >> the memory attributes of the initrd config table should be such that
> it
> > >> can be recovered for normal use. That may be tricky though.
> > >>
> > >
> > > The purpose of the EFI_FILE_LOAD2_PROTOCOL based initrd loading
> mechanism
> > > is to allow the EFI stub (which is tightly coupled to the kernel
> > > arch/version/etc) to allocate the memory for the initrd, and pass it
> into
> > > the LoadFile2() request, using whichever policy it wants to adhere to
> for
> > > alignment, offset and/or vicinity of the kernel image. It also ens
Re: [PULL] Pull request for u-boot-stm/next = u-boot-stm32-20201003
On Mon, Oct 05, 2020 at 08:44:45AM +, Patrick DELAUNAY wrote: > Hi Tom, > > Please pull the STM32 related patches for u-boot/next: u-boot-stm32-20201003 > > With STM32 updates for v2021.01-rc1: > - stm32mp: DT alignment with Linux 5.9-rc4 > - stm32mp: convert drivers to APIs which support live DT > - stm32mp: gpio: minor fixes > > CI status: > https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/4880 > > Thanks, > Patrick > > git request-pull origin/next > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20201003 > > > The following changes since commit 7e373a1a6ac27492ffebba146d70c4d39a9b9f36: > > Merge branch 'next' of git://git.denx.de/u-boot-usb into next (2020-10-01 > 14:52:56 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20201003 > > for you to fetch changes up to 04e29ca5bbb82f15d7a32d4130214c6a15db69aa: > > mailbox: stm32_ipcc: Convert to use APIs which support live DT (2020-10-02 > 15:05:14 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-atmel-2021.01-a
On Mon, Oct 05, 2020 at 11:33:24AM +, eugen.hris...@microchip.com wrote: > Hello Tom, > > Please pull tag u-boot-atmel-2021.01-a , the first set of new features > for the 2021.01 cycle. > > This feature set includes a new CPU driver for at91 family, new driver > for PIT64B hardware timer, support for new at91 family SoC named sama7g5 > which adds: clock support, including conversion of the clock tree to > CCF; SoC support in mach-at91, pinctrl and mmc drivers update. > The feature set also includes updates for mmc driver and some other > minor fixes and features regarding building without the old Atmel PIT > and the possibility to read a secondary MAC address from a second i2c > EEPROM. > > Thanks ! > Eugen > > The following changes since commit ba2a0cbb053951ed6d36161989d38da724696b4d: > >Prepare v2020.10-rc5 (2020-09-21 13:45:23 -0400) > > are available in the Git repository at: > >https://gitlab.denx.de/u-boot/custodians/u-boot-atmel.git > tags/u-boot-atmel-2021.01-a > > for you to fetch changes up to 01c35f269f21398fa9d1db1b90b73f7e95a3bf22: > >cpu: at91: add driver for CPU (2020-10-05 10:45:16 +0300) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] arm: mvebu: Espressobin: Set environment variable fdtfile
On 03/10/2020 10:50, Pali Rohár wrote:
On Saturday 03 October 2020 09:17:35 Andre Heider wrote:
On 02/10/2020 12:49, Pali Rohár wrote:
On Saturday 26 September 2020 11:09:59 Andre Heider wrote:
On 25/09/2020 09:46, Pali Rohár wrote:
On Friday 11 September 2020 06:35:10 Andre Heider wrote:
...
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ bool ddr4, emmc;
+
+ if (env_get("fdtfile"))
+ return 0;
+
+ if (!of_machine_is_compatible("globalscale,espressobin"))
+ return 0;
+
+ /* If the memory controller has been configured for DDR4, we're running
on v7 */
+ ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
+ & A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
+
+ emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
Maybe stupid question, but are not we able to detect if eMMC is
connected or not at runtime? That could simplify setup and avoid usage
of additional special DTS file for eMMC in U-Boot.
At some point I wondered about the same.
IIRC armbian just enables it and uses one u-boot binary everywhere. A
non-existing chip won't get detected, so that shouldn't be a problem.
But I think it has more to do with enabling/powering up hardware blocks,
which is not wanted or may even problematic.
In U-Boot such functionality may be implemented in board_fix_fdt()
function which allows U-Boot to modify its Device tree prior using it.
You have already wrote code which is doing V5 vs V7 detection, so
detecting eMMC is the last thing which is missing to have just one
U-Boot DTS file and therefore only one U-Boot binary for Espressobin.
That implies setting status=okay for the emmc node, which then powers up
that block. I don't know if that might be problematic. Can we just do that?
No. I mean to detect presence of eMMC in board_fix_fdt() and then set
tatus=okay only if check passed.
Yes, but how do you detect the emmc then? Enabling it in u-boot's dts
and calling mmc_init() on it would be the easy way, but open coding all
the required parts to do that with status=disabled could get rather big
and/or unmaintanable (I didn't check what exactly would be required)?
The emmc detection would also add some delay to the boot process.
At least it should be powered down if no emmc chip has been detected, but I
didn't check if that happens right now.
Regards,
Andre
Re: [PATCH] pwm: Add driver for Amlogic Meson PWM controller
On 02/10/2020 11:09, Neil Armstrong via groups.io wrote:
> This adds the driver for the PWM controller found in the Amlogic SoCs.
>
> This PWM is only a set of Gates, Dividers and Counters:
> PWM output is achieved by calculating a clock that permits calculating
> two periods (low and high). The counter then has to be set to switch after
> N cycles for the first half period.
> The hardware has no "polarity" setting. This driver reverses the period
> cycles (the low length is inverted with the high length) for
> PWM_POLARITY_INVERSED.
>
> Disabling the PWM stops the output immediately (without waiting for the
> current period to complete first).
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/pwm/Kconfig | 7 +
> drivers/pwm/Makefile| 1 +
> drivers/pwm/pwm-meson.c | 528
> 3 files changed, 536 insertions(+)
> create mode 100644 drivers/pwm/pwm-meson.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 61eb468cde..b3bd5c6bb7 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -23,6 +23,13 @@ config PWM_IMX
> help
> This PWM is found i.MX27 and later i.MX SoCs.
>
> +config PWM_MESON
> + bool "Enable support for Amlogic Meson SoCs PWM"
> + depends on DM_PWM
> + help
> + This PWM is found on Amlogic Meson SoCs. It supports a
> + programmable period and duty cycle for 2 independant channels.
> +
> config PWM_MTK
> bool "Enable support for MediaTek PWM"
> depends on DM_PWM
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0f4e84b04d..f21ae7d76e 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_DM_PWM)+= pwm-uclass.o
>
> obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o
> obj-$(CONFIG_PWM_IMX)+= pwm-imx.o pwm-imx-util.o
> +obj-$(CONFIG_PWM_MESON) += pwm-meson.o
> obj-$(CONFIG_PWM_MTK)+= pwm-mtk.o
> obj-$(CONFIG_PWM_ROCKCHIP) += rk_pwm.o
> obj-$(CONFIG_PWM_SANDBOX)+= sandbox_pwm.o
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> new file mode 100644
> index 00..cafb571f16
> --- /dev/null
> +++ b/drivers/pwm/pwm-meson.c
> @@ -0,0 +1,528 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Copyright (C) 2020 BayLibre, SAS.
> + * Author: Neil Armstrong
> + * Copyright (C) 2014 Amlogic, Inc.
> + *
> + * This PWM is only a set of Gates, Dividers and Counters:
> + * PWM output is achieved by calculating a clock that permits calculating
> + * two periods (low and high). The counter then has to be set to switch after
> + * N cycles for the first half period.
> + * The hardware has no "polarity" setting. This driver reverses the period
> + * cycles (the low length is inverted with the high length) for
> + * PWM_POLARITY_INVERSED.
> + * Setting the polarity will disable and re-enable the PWM output.
> + * Disabling the PWM stops the output immediately (without waiting for the
> + * current period to complete first).
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NSEC_PER_SEC 10L
> +
> +#define REG_PWM_A0x0
> +#define REG_PWM_B0x4
> +#define PWM_LOW_MASK GENMASK(15, 0)
> +#define PWM_HIGH_MASKGENMASK(31, 16)
> +
> +#define REG_MISC_AB 0x8
> +#define MISC_B_CLK_ENBIT(23)
> +#define MISC_A_CLK_ENBIT(15)
> +#define MISC_CLK_DIV_MASK0x7f
> +#define MISC_B_CLK_DIV_SHIFT 16
> +#define MISC_A_CLK_DIV_SHIFT 8
> +#define MISC_B_CLK_SEL_SHIFT 6
> +#define MISC_A_CLK_SEL_SHIFT 4
> +#define MISC_CLK_SEL_MASK0x3
> +#define MISC_B_ENBIT(1)
> +#define MISC_A_ENBIT(0)
> +
> +#define MESON_NUM_PWMS 2
> +
> +static struct meson_pwm_channel_data {
> + u8 reg_offset;
> + u8 clk_sel_shift;
> + u8 clk_div_shift;
> + u32 clk_en_mask;
> + u32 pwm_en_mask;
> +} meson_pwm_per_channel_data[MESON_NUM_PWMS] = {
> + {
> + .reg_offset = REG_PWM_A,
> + .clk_sel_shift = MISC_A_CLK_SEL_SHIFT,
> + .clk_div_shift = MISC_A_CLK_DIV_SHIFT,
> + .clk_en_mask= MISC_A_CLK_EN,
> + .pwm_en_mask= MISC_A_EN,
> + },
> + {
> + .reg_offset = REG_PWM_B,
> + .clk_sel_shift = MISC_B_CLK_SEL_SHIFT,
> + .clk_div_shift = MISC_B_CLK_DIV_SHIFT,
> + .clk_en_mask= MISC_B_CLK_EN,
> + .pwm_en_mask= MISC_B_EN,
> + }
> +};
> +
> +struct meson_pwm_channel {
> + unsigned int hi;
> + unsigned int lo;
> + u8 pre_div;
> + uint period_ns;
> + uint duty_ns;
> + bool configured;
> + bool enabled;
> + bool polarity;
> + struct clk clk;
> +};
> +
> +stru
Re: [PATCH 1/2] pinctrl: meson-axg-pmx: fix gpio request
On 02/10/2020 11:05, Neil Armstrong wrote:
> The AXG pmx driver gpio request offset needs the pin base to have the
> correct pin number.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> index c6cb941d0a..cfe94cf9e1 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> @@ -165,7 +165,10 @@ const struct pinctrl_ops meson_axg_pinctrl_ops = {
> static int meson_axg_gpio_request(struct udevice *dev,
> unsigned int offset, const char *label)
> {
> - return meson_axg_pmx_update_function(dev->parent, offset, 0);
> + struct meson_pinctrl *priv = dev_get_priv(dev->parent);
> +
> + return meson_axg_pmx_update_function(dev->parent,
> + offset + priv->data->pin_base, 0);
> }
>
> static const struct dm_gpio_ops meson_axg_gpio_ops = {
>
Applied both to u-boot-amlogic
Neil
[PULL] u-boot-atmel-2021.01-a
Hello Tom, Please pull tag u-boot-atmel-2021.01-a , the first set of new features for the 2021.01 cycle. This feature set includes a new CPU driver for at91 family, new driver for PIT64B hardware timer, support for new at91 family SoC named sama7g5 which adds: clock support, including conversion of the clock tree to CCF; SoC support in mach-at91, pinctrl and mmc drivers update. The feature set also includes updates for mmc driver and some other minor fixes and features regarding building without the old Atmel PIT and the possibility to read a secondary MAC address from a second i2c EEPROM. Thanks ! Eugen The following changes since commit ba2a0cbb053951ed6d36161989d38da724696b4d: Prepare v2020.10-rc5 (2020-09-21 13:45:23 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-atmel.git tags/u-boot-atmel-2021.01-a for you to fetch changes up to 01c35f269f21398fa9d1db1b90b73f7e95a3bf22: cpu: at91: add driver for CPU (2020-10-05 10:45:16 +0300) First set of u-boot-atmel features for 2021.01 cycle Claudiu Beznea (24): clk: check hw and hw->dev before dereference it dm: core: add support for device re-parenting clk: bind clk to new parent device clk: do not disable clock if it is critical clk: get clock pointer before proceeding clk: at91: add pre-requisite headers for AT91 clock architecture clk: at91: pmc: add helpers for clock drivers clk: at91: move clock code to compat.c clk: at91: sckc: add driver compatible with ccf clk: at91: clk-main: add driver compatible with ccf clk: at91: sam9x60-pll: add driver compatible with ccf clk: at91: clk-master: add driver compatible with ccf clk: at91: clk-master: add support for sama7g5 clk: at91: clk-utmi: add driver compatible with ccf clk: at91: clk-utmi: add support for sama7g5 clk: at91: clk-programmable: add driver compatible with ccf clk: at91: clk-system: add driver compatible with ccf clk: at91: clk-peripheral: add driver compatible with ccf clk: at91: clk-generic: add driver compatible with ccf clk: at91: pmc: add generic clock ops clk: at91: sama7g5: add clock support timer: mchp-pit64b: add support for pit64b MAINTAINERS: add Microchip PIT64B timer cpu: at91: add driver for CPU Eugen Hristev (8): board: atmel: common: introduce at91_set_eth1addr for second interface ARM: at91: common: guard ATMEL_PIT code by ifdef ARM: mach-at91: add support for new SoC sama7g5 pinctrl: at91-pio4: add compatible for sama7g5 pinctrl block mmc: atmel-sdhci: add sama7g5-sdhci compatibility string mmc: atmel-sdhci: do not check clk_set_rate return value mmc: atmel-sdhci: enable the required generic clock mmc: atmel-sdhci: use mmc_of_parse to get the DT properties MAINTAINERS |2 + arch/arm/dts/sama7g5-pinfunc.h| 924 arch/arm/mach-at91/Kconfig|4 + arch/arm/mach-at91/armv7/Makefile |1 + arch/arm/mach-at91/armv7/cpu.c|2 + arch/arm/mach-at91/armv7/sama7g5_devices.c| 11 + arch/arm/mach-at91/include/mach/at91_common.h |1 + arch/arm/mach-at91/include/mach/hardware.h|2 + arch/arm/mach-at91/include/mach/sama7g5.h | 74 ++ board/atmel/common/mac_eeprom.c | 33 + drivers/clk/at91/Kconfig |7 + drivers/clk/at91/Makefile | 15 +- drivers/clk/at91/clk-generated.c | 178 drivers/clk/at91/clk-generic.c| 202 drivers/clk/at91/clk-h32mx.c | 56 - drivers/clk/at91/clk-main.c | 381 ++- drivers/clk/at91/clk-master.c | 331 +- drivers/clk/at91/clk-peripheral.c | 291 +++-- drivers/clk/at91/clk-plla.c | 54 - drivers/clk/at91/clk-plladiv.c| 85 -- drivers/clk/at91/clk-programmable.c | 208 drivers/clk/at91/clk-sam9x60-pll.c| 442 drivers/clk/at91/clk-slow.c | 36 - drivers/clk/at91/clk-system.c | 143 +-- drivers/clk/at91/clk-usb.c| 147 --- drivers/clk/at91/clk-utmi.c | 234 +++-- drivers/clk/at91/compat.c | 1023 ++ drivers/clk/at91/pmc.c| 218 ++-- drivers/clk/at91/pmc.h| 140 ++- drivers/clk/at91/sama7g5.c| 1401 + drivers/clk/at91/sckc.c | 169 ++- drivers/clk/clk-uclass.c | 51 +- drive
Re: Fit images and EFI_LOAD_FILE2_PROTOCOL
On Mon, Oct 05, 2020 at 04:12:11PM +0200, François Ozog wrote:
> The driving idea is that there is an existing bootflow, non UEFI that
> allows vmlinuz, initrd and DTB to be protected in a single FIT. The
> trustworthiness of the solution is higher that regular distro on pure UEFI
> systems but does not allow initrd changes as you install stuff. We need to
> keep in mind the use cases: most of the cases are for production devices
> where updates are not "calculated" in place but rather deployed with
> various means.
>
> I'd like to define two EBBR boot flows:
> 1) typical distro (with its weakness)
> 2) typical embedded (as of today, addressing security and mix/match
> protection)
>
> The 1) is described in slide 4 of the deck
> The 2) is described in slide 5.
It seems these discussion keeps looping back to out-of-band resources.
If we have to keep referring to out-of-band resources to follow
discussion can you ensure there is a link to said out-of-band resources
when citing modifications to them.
It's frustrating to have to go rummaging through my mail archives to find
your doc.
Daniel.
>
> The UEFI interface is still OS independent but comes with an additional
> opportunity: the ESP File System is "merged" with contents of a FIT (kind
> of overlayfs). This way the content of the FIT can be checked and EFIStub
> with EFI-LOAD_FILE2 the initrd. The boot will still indirectly point to
> the FIT contained .EFI application, the firmware DTB may be overwritten by
> a FIT DTB.
>
> Is this a better scenario to establish 2)?
>
> Cheers
>
>
> FF
>
> On Sat, 3 Oct 2020 at 15:12, Ard Biesheuvel wrote:
>
> >
> >
> > On Sat, 3 Oct 2020 at 13:16, François Ozog
> > wrote:
> >
> >>
> >>
> >> Le sam. 3 oct. 2020 à 13:14, François Ozog a
> >> écrit :
> >>
> >>>
> >>>
> >>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt a
> >>> écrit :
> >>>
> Hello Ilias, hello Christian,
>
>
>
> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for initramfs
>
> loading") Ilias provided the possibility to specify a device path
>
> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
>
> served via the EFI_FILE_LOAD2_PROTOCOL.
>
>
>
> Ard extended the Linux EFI stub to allow loading the initial RAM disk
>
> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
>
>
>
> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
>
> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
>
> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
>
>
>
> In the DTE calls we have discussed that it is unfortunate that we do not
>
> have a method to validate initial RAM images in the UEFI context.
>
>
>
> To me it would look like a good path forward to combine the two ideas:
>
>
>
> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
>
> * Pass location and size to the UEFI subsystem and serve them via
>
> the EFI_FILE_LOAD2_PROTOCOL.
>
>
>
> We could also extend the bootefi command to be callable as
>
>
>
> bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
>
>
>
> like the booti command to serve an initial RAM disk.
>
>
>
> What are your thoughts?
> >>>
> >>> that looks super interesting.
> >>> I propose something (in the latest desk preparing oct 14th) similar
> >>> except the an efi application boots the FIT.
> >>> I view UEFI as booting a PE coff and pass a set of config tables. Today
> >>> we have DTB, we could just add Initrd (you command line). Bootefi would be
> >>> responsible to valide the containing FIT before pushing initrd (and
> >>> dTB?)into the table. It would be the responsibility of the efi stub to get
> >>> the initrd from the config table (GUID to be defined).
> >>>
> >> the memory attributes of the initrd config table should be such that it
> >> can be recovered for normal use. That may be tricky though.
> >>
> >
> > The purpose of the EFI_FILE_LOAD2_PROTOCOL based initrd loading mechanism
> > is to allow the EFI stub (which is tightly coupled to the kernel
> > arch/version/etc) to allocate the memory for the initrd, and pass it into
> > the LoadFile2() request, using whichever policy it wants to adhere to for
> > alignment, offset and/or vicinity of the kernel image. It also ensures that
> > any measurement performed by the bootloader for attestation or
> > authentication can be delayed to the point where the booting kernel assumes
> > ownership of the initrd contents, preventing potential TOCTOU issues where
> > intermediate boot stages are involved (shim+grub etc)
> >
> > Creating an initrd config table would mean that the bootloader decides
> > where to load the initrd in memory, and only passes the address and size.
> > This is exact
[ANN] U-Boot v2020.10 released
Hey all, It is release day and here is the v2020.10 release. With this release we have a number of "please migrate to DM" warnings that are now 1 year past their warning date, and well past 1 year of those warnings being printed. It's getting up there on my TODO list to see if removing features or boards in these cases is easier. In terms of a changelog, git log --merges v2020.10-rc5..v2020.10 or git log --merges v2020.07..v2020.10 The merge window is once again open and I plan to tag -rc1 on Monday, October 26th, bi-weekly -rcs thereafter and final release on January 11th, 2021. I am merging the next branch to master shortly and will send a separate email when that is done. -- Tom signature.asc Description: PGP signature
Re: Fit images and EFI_LOAD_FILE2_PROTOCOL
The driving idea is that there is an existing bootflow, non UEFI that
allows vmlinuz, initrd and DTB to be protected in a single FIT. The
trustworthiness of the solution is higher that regular distro on pure UEFI
systems but does not allow initrd changes as you install stuff. We need to
keep in mind the use cases: most of the cases are for production devices
where updates are not "calculated" in place but rather deployed with
various means.
I'd like to define two EBBR boot flows:
1) typical distro (with its weakness)
2) typical embedded (as of today, addressing security and mix/match
protection)
The 1) is described in slide 4 of the deck
The 2) is described in slide 5.
The UEFI interface is still OS independent but comes with an additional
opportunity: the ESP File System is "merged" with contents of a FIT (kind
of overlayfs). This way the content of the FIT can be checked and EFIStub
with EFI-LOAD_FILE2 the initrd. The boot will still indirectly point to
the FIT contained .EFI application, the firmware DTB may be overwritten by
a FIT DTB.
Is this a better scenario to establish 2)?
Cheers
FF
On Sat, 3 Oct 2020 at 15:12, Ard Biesheuvel wrote:
>
>
> On Sat, 3 Oct 2020 at 13:16, François Ozog
> wrote:
>
>>
>>
>> Le sam. 3 oct. 2020 à 13:14, François Ozog a
>> écrit :
>>
>>>
>>>
>>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt a
>>> écrit :
>>>
Hello Ilias, hello Christian,
with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for initramfs
loading") Ilias provided the possibility to specify a device path
(CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
served via the EFI_FILE_LOAD2_PROTOCOL.
Ard extended the Linux EFI stub to allow loading the initial RAM disk
via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
IH_OS_EFI") Cristian enabled signed FIT images that contain a device
tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
In the DTE calls we have discussed that it is unfortunate that we do not
have a method to validate initial RAM images in the UEFI context.
To me it would look like a good path forward to combine the two ideas:
* Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
* Pass location and size to the UEFI subsystem and serve them via
the EFI_FILE_LOAD2_PROTOCOL.
We could also extend the bootefi command to be callable as
bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
like the booti command to serve an initial RAM disk.
What are your thoughts?
>>>
>>> that looks super interesting.
>>> I propose something (in the latest desk preparing oct 14th) similar
>>> except the an efi application boots the FIT.
>>> I view UEFI as booting a PE coff and pass a set of config tables. Today
>>> we have DTB, we could just add Initrd (you command line). Bootefi would be
>>> responsible to valide the containing FIT before pushing initrd (and
>>> dTB?)into the table. It would be the responsibility of the efi stub to get
>>> the initrd from the config table (GUID to be defined).
>>>
>> the memory attributes of the initrd config table should be such that it
>> can be recovered for normal use. That may be tricky though.
>>
>
> The purpose of the EFI_FILE_LOAD2_PROTOCOL based initrd loading mechanism
> is to allow the EFI stub (which is tightly coupled to the kernel
> arch/version/etc) to allocate the memory for the initrd, and pass it into
> the LoadFile2() request, using whichever policy it wants to adhere to for
> alignment, offset and/or vicinity of the kernel image. It also ensures that
> any measurement performed by the bootloader for attestation or
> authentication can be delayed to the point where the booting kernel assumes
> ownership of the initrd contents, preventing potential TOCTOU issues where
> intermediate boot stages are involved (shim+grub etc)
>
> Creating an initrd config table would mean that the bootloader decides
> where to load the initrd in memory, and only passes the address and size.
> This is exactly what we wanted to avoid, because now, the bootloader has to
> know all these different rules that vary between kernel version,
> configurations and architectures.
>
> For uboot's implementation of FIT based EFI_FILE_LOAD2_PROTOCOL, this
> might mean that the initrd is loaded into memory first, and copied to
> another location (and [re-]authenticated) when LoadFile2() is invoked. I
> don't think this is a problem in the general case, but we might think about
> ways to avoid this if this turns out to be a problem for memory constrained
> devices with huge initrds.
>
>
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.648
verified boot changes since 2020.04
Hi,
I'm trying to keep our board in sync with upstream, but when trying to
port it to v2020.10-rc4, the kernel verification fails:
## Loading kernel from FIT Image at 0300 ...
Using 'conf-def.dtb' configuration
Verifying Hash Integrity ... sha1,rsa2048:dev- error!
Verification failed for '' hash node in 'conf-def.dtb' config node
Failed to verify required signature 'key-dev'
Bad Data Hash
ERROR: can't get kernel image!
Our current board code is based on v2020.04 where everything works as
expected.
I have checked that U-Boot's .dtb has identical /signature nodes between
the two versions, both from within U-Boot with 'fdt print /signature'
and using fdtdump:
=> fdt print /signature
signature {
key-dev {
required = "conf";
algo = "sha1,rsa2048";
rsa,r-squared = ...
rsa,modulus = ...
rsa,exponent = ...
rsa,n0-inverse = ...
rsa,num-bits = <0x0800>;
key-name-hint = "dev";
};
};
(except that apparently the new version of U-Boot no longer abbreviates
the r-squared and modulus values to an "* adress [length]" format).
I wanted to try using tools/fit_check_sign as a quick way to bisect
this, unfortunately the v2020.10-rc4 version (also) says that the kernel
image is correctly signed.
Does anyone have a crystal ball that says what might have changed to
cause this? The board in question is based on mpc8309, i.e. big-endian
powerpc.
Thanks,
Rasmus
[PATCH 2/3] dm_qe_uec.c: fix indentation in uec_set_mac_if_mode()
Signed-off-by: Rasmus Villemoes
---
drivers/net/qe/dm_qe_uec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qe/dm_qe_uec.c b/drivers/net/qe/dm_qe_uec.c
index 3482b3ff17..e2b8bf02f9 100644
--- a/drivers/net/qe/dm_qe_uec.c
+++ b/drivers/net/qe/dm_qe_uec.c
@@ -171,8 +171,8 @@ static int uec_set_mac_if_mode(struct uec_priv *uec)
break;
default:
return -EINVAL;
- }
- break;
+ }
+ break;
case SPEED_1000:
maccfg2 |= MACCFG2_INTERFACE_MODE_BYTE;
switch (enet_if_mode) {
--
2.23.0
[PATCH 3/3] uec.h: fix COFIG_DM typo
Signed-off-by: Rasmus Villemoes
---
drivers/net/qe/uec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/qe/uec.h b/drivers/net/qe/uec.h
index 7cd4b8737a..32b7d3e561 100644
--- a/drivers/net/qe/uec.h
+++ b/drivers/net/qe/uec.h
@@ -678,7 +678,7 @@ struct uec_priv {
int grace_stopped_tx;
int grace_stopped_rx;
int the_first_run;
-#if !defined(COFIG_DM)
+#if !defined(CONFIG_DM)
/* PHY specific */
struct uec_mii_info *mii_info;
int oldspeed;
--
2.23.0
[PATCH 1/3] mdio-uclass.c: support fixed-link subnodes
When trying to port our mpc8309-based board to DM_ETH, on top of
Heiko's patches, I found that nothing in mdio-uclass.c seems to
support the use of a fixed-link subnode of the ethernet DT node. That
is, the ethernet node looks like
enet0: ethernet@2000 {
device_type = "network";
compatible = "ucc_geth";
...
fixed-link {
reg = <0x>;
speed = <100>;
full-duplex;
};
but the current code expects there to be phy-handle property. Adding
that, i.e.
phy-handle = <&enet0phy>;
enet0phy: fixed-link {
just makes the code break a few lines later since a fixed-link node
doesn't have a reg property. Ignoring the dtc complaint and adding a
dummy reg property, we of course hit "can't find MDIO bus for node
ethernet@2000" since indeed, the parent node of the phy node does not
represent an MDIO bus. So that's obviously the wrong path.
Now, in linux, it seems that the fixed link case is treated specially;
in the of_phy_get_and_connect() which roughly corresponds to
dm_eth_connect_phy_handle() we have
if (of_phy_is_fixed_link(np)) {
ret = of_phy_register_fixed_link(np);
...
} else {
phy_np = of_parse_phandle(np, "phy-handle", 0);
...
}
phy = of_phy_connect(dev, phy_np, hndlr, 0, iface);
And U-Boot's phy_connect() does have support for fixed-link
subnodes. Calling phy_connect() directly with NULL bus and a dummy
address does seem to make the ethernet work.
Signed-off-by: Rasmus Villemoes
---
net/mdio-uclass.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index 66ee2e1976..2f932b77df 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -139,6 +139,12 @@ static struct phy_device *dm_eth_connect_phy_handle(struct
udevice *ethdev,
struct ofnode_phandle_args phandle = {.node = ofnode_null()};
int i;
+ if (CONFIG_IS_ENABLED(PHY_FIXED) &&
+ ofnode_valid(dev_read_subnode(ethdev, "fixed-link"))) {
+ phy = phy_connect(NULL, -1, ethdev, interface);
+ goto out;
+ }
+
for (i = 0; i < PHY_HANDLE_STR_CNT; i++)
if (!dev_read_phandle_with_args(ethdev, phy_handle_str[i], NULL,
0, 0, &phandle))
@@ -168,6 +174,7 @@ static struct phy_device *dm_eth_connect_phy_handle(struct
udevice *ethdev,
phy = dm_mdio_phy_connect(mdiodev, phy_addr, ethdev, interface);
+out:
if (phy)
phy->node = phandle.node;
--
2.23.0
[PATCH 0/3] DM_ETH v mpc83xx fixups
Hi Heiko I finally managed to figure out what was wrong; the fixed-link phy was simply ignored. This is fixed by the first patch, though I don't know if that's the proper way to make this work. While poking around the code I found two minor things that might as well be fixed. I'd also like to do a somewhat more extensive change to dm_qe_uec.c: I find it very confusing with the qe_uec_priv versus uec_priv, so I'd like to just add a phydev member to struct uec_priv, remove struct qe_uec_priv, make .priv_auto_alloc_size = sizeof(struct uec_priv), and eliminate the malloc/free pair in .prove/.remove. It's mostly mechanical using coccinelle, but WDYT? Rasmus Villemoes (3): mdio-uclass.c: support fixed-link subnodes dm_qe_uec.c: fix indentation in uec_set_mac_if_mode() uec.h: fix COFIG_DM typo drivers/net/qe/dm_qe_uec.c | 4 ++-- drivers/net/qe/uec.h | 2 +- net/mdio-uclass.c | 7 +++ 3 files changed, 10 insertions(+), 3 deletions(-) -- 2.23.0
Re: [GIT PULL] u-boot-rpi/rpi-next to next
On Fri, Oct 02, 2020 at 05:37:25PM +0200, Matthias Brugger wrote: > Hi Tom, > > I have a few patches for the next branch, please pull :) > > Regards, > Matthias > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] cpu: at91: add driver for CPU
On 01.10.2020 13:27, Claudiu Beznea wrote: > Add basic CPU driver use to retrieve information about CPU itself. > > Signed-off-by: Claudiu Beznea > --- > > Changes in v2: > - get rid of compilation warnings > - rebase on top of "MAINTAINERS: add Microchip PIT64B timer" patch > > MAINTAINERS| 1 + > drivers/cpu/Makefile | 1 + > drivers/cpu/at91_cpu.c | 123 > + > 3 files changed, 125 insertions(+) > create mode 100644 drivers/cpu/at91_cpu.c Applied to u-boot-atmel/next Thanks !
[PATCH 2/2] x86: Fix up driver names to avoid dtoc warnings
At present there are a lot of dtoc warnings reported when building
chromebook_coral, of the form:
WARNING: the driver intel_apl_lpc was not found in the driver list
Correct these by using driver names that matches their compatible string.
Signed-off-by: Simon Glass
---
arch/x86/cpu/apollolake/cpu.c| 4 ++--
arch/x86/cpu/apollolake/hostbridge.c | 2 +-
arch/x86/cpu/apollolake/lpc.c| 2 +-
arch/x86/cpu/apollolake/pch.c| 4 ++--
arch/x86/cpu/apollolake/pmc.c| 2 +-
arch/x86/cpu/apollolake/punit.c | 4 ++--
arch/x86/cpu/apollolake/uart.c | 2 +-
arch/x86/cpu/intel_common/itss.c | 2 +-
arch/x86/cpu/intel_common/p2sb.c | 2 +-
drivers/gpio/intel_gpio.c| 4 ++--
drivers/pinctrl/intel/pinctrl_apl.c | 2 +-
drivers/rtc/mc146818.c | 4 ++--
drivers/sysreset/sysreset_x86.c | 4 ++--
drivers/timer/tsc_timer.c| 4 ++--
14 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/x86/cpu/apollolake/cpu.c b/arch/x86/cpu/apollolake/cpu.c
index 8da2e64e226..a4c9c96cfdc 100644
--- a/arch/x86/cpu/apollolake/cpu.c
+++ b/arch/x86/cpu/apollolake/cpu.c
@@ -102,8 +102,8 @@ static const struct udevice_id cpu_x86_apl_ids[] = {
{ }
};
-U_BOOT_DRIVER(cpu_x86_apl_drv) = {
- .name = "cpu_x86_apl",
+U_BOOT_DRIVER(intel_apl_cpu) = {
+ .name = "intel_apl_cpu",
.id = UCLASS_CPU,
.of_match = cpu_x86_apl_ids,
.bind = cpu_x86_bind,
diff --git a/arch/x86/cpu/apollolake/hostbridge.c
b/arch/x86/cpu/apollolake/hostbridge.c
index 7fd67dcfb6e..cafd9d65b24 100644
--- a/arch/x86/cpu/apollolake/hostbridge.c
+++ b/arch/x86/cpu/apollolake/hostbridge.c
@@ -396,7 +396,7 @@ static const struct udevice_id apl_hostbridge_ids[] = {
{ }
};
-U_BOOT_DRIVER(apl_hostbridge_drv) = {
+U_BOOT_DRIVER(intel_apl_hostbridge) = {
.name = "intel_apl_hostbridge",
.id = UCLASS_NORTHBRIDGE,
.of_match = apl_hostbridge_ids,
diff --git a/arch/x86/cpu/apollolake/lpc.c b/arch/x86/cpu/apollolake/lpc.c
index a29832c879a..d8e05f6a8f4 100644
--- a/arch/x86/cpu/apollolake/lpc.c
+++ b/arch/x86/cpu/apollolake/lpc.c
@@ -133,7 +133,7 @@ static const struct udevice_id apl_lpc_ids[] = {
};
/* All pads are LPC already configured by the hostbridge, so no probing here */
-U_BOOT_DRIVER(apl_lpc_drv) = {
+U_BOOT_DRIVER(intel_apl_lpc) = {
.name = "intel_apl_lpc",
.id = UCLASS_LPC,
.of_match = apl_lpc_ids,
diff --git a/arch/x86/cpu/apollolake/pch.c b/arch/x86/cpu/apollolake/pch.c
index 1a5a985221f..d9832ff2496 100644
--- a/arch/x86/cpu/apollolake/pch.c
+++ b/arch/x86/cpu/apollolake/pch.c
@@ -28,8 +28,8 @@ static const struct udevice_id apl_pch_ids[] = {
{ }
};
-U_BOOT_DRIVER(apl_pch) = {
- .name = "apl_pch",
+U_BOOT_DRIVER(intel_apl_pch) = {
+ .name = "intel_apl_pch",
.id = UCLASS_PCH,
.of_match = apl_pch_ids,
.ops= &apl_pch_ops,
diff --git a/arch/x86/cpu/apollolake/pmc.c b/arch/x86/cpu/apollolake/pmc.c
index 576d0187570..cacaa007e05 100644
--- a/arch/x86/cpu/apollolake/pmc.c
+++ b/arch/x86/cpu/apollolake/pmc.c
@@ -217,7 +217,7 @@ static const struct udevice_id apl_pmc_ids[] = {
{ }
};
-U_BOOT_DRIVER(apl_pmc) = {
+U_BOOT_DRIVER(intel_apl_pmc) = {
.name = "intel_apl_pmc",
.id = UCLASS_ACPI_PMC,
.of_match = apl_pmc_ids,
diff --git a/arch/x86/cpu/apollolake/punit.c b/arch/x86/cpu/apollolake/punit.c
index e76f2805d7f..e67c011e22c 100644
--- a/arch/x86/cpu/apollolake/punit.c
+++ b/arch/x86/cpu/apollolake/punit.c
@@ -88,8 +88,8 @@ static const struct udevice_id apl_syscon_ids[] = {
{ }
};
-U_BOOT_DRIVER(syscon_intel_punit) = {
- .name = "intel_punit_syscon",
+U_BOOT_DRIVER(intel_apl_punit) = {
+ .name = "intel_apl_punit",
.id = UCLASS_SYSCON,
.of_match = apl_syscon_ids,
.probe = apl_punit_probe,
diff --git a/arch/x86/cpu/apollolake/uart.c b/arch/x86/cpu/apollolake/uart.c
index f368f7d2db4..c522aa97803 100644
--- a/arch/x86/cpu/apollolake/uart.c
+++ b/arch/x86/cpu/apollolake/uart.c
@@ -122,7 +122,7 @@ static const struct udevice_id apl_ns16550_serial_ids[] = {
{ },
};
-U_BOOT_DRIVER(apl_ns16550) = {
+U_BOOT_DRIVER(intel_apl_ns16550) = {
.name = "intel_apl_ns16550",
.id = UCLASS_SERIAL,
.of_match = apl_ns16550_serial_ids,
diff --git a/arch/x86/cpu/intel_common/itss.c b/arch/x86/cpu/intel_common/itss.c
index fe84ebe29f7..53dd09d8f54 100644
--- a/arch/x86/cpu/intel_common/itss.c
+++ b/arch/x86/cpu/intel_common/itss.c
@@ -235,7 +235,7 @@ static const struct udevice_id itss_ids[] = {
{ }
};
-U_BOOT_DRIVER(itss_drv) = {
+U_BOOT_DRIVER(intel_itss) = {
.name = "intel_itss
[PATCH 1/2] cros_ec: Fix up driver names to avoid dtoc warnings
Fix the dtoc warning in these file by using a driver name that matches the
compatible string.
Signed-off-by: Simon Glass
---
drivers/misc/cros_ec_i2c.c | 4 ++--
drivers/misc/cros_ec_lpc.c | 4 ++--
drivers/misc/cros_ec_spi.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/cros_ec_i2c.c b/drivers/misc/cros_ec_i2c.c
index c00f5f764a0..664bd2b9385 100644
--- a/drivers/misc/cros_ec_i2c.c
+++ b/drivers/misc/cros_ec_i2c.c
@@ -231,8 +231,8 @@ static const struct udevice_id cros_ec_ids[] = {
{ }
};
-U_BOOT_DRIVER(cros_ec_i2c) = {
- .name = "cros_ec_i2c",
+U_BOOT_DRIVER(google_cros_ec_i2c) = {
+ .name = "google_cros_ec_i2c",
.id = UCLASS_CROS_EC,
.of_match = cros_ec_ids,
.probe = cros_ec_probe,
diff --git a/drivers/misc/cros_ec_lpc.c b/drivers/misc/cros_ec_lpc.c
index 4ad6c8ca66d..63702f90fbc 100644
--- a/drivers/misc/cros_ec_lpc.c
+++ b/drivers/misc/cros_ec_lpc.c
@@ -243,8 +243,8 @@ static const struct udevice_id cros_ec_ids[] = {
{ }
};
-U_BOOT_DRIVER(cros_ec_lpc) = {
- .name = "cros_ec_lpc",
+U_BOOT_DRIVER(google_cros_ec_lpc) = {
+ .name = "google_cros_ec_lpc",
.id = UCLASS_CROS_EC,
.of_match = cros_ec_ids,
.probe = cros_ec_probe,
diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
index 153f971bdeb..bbc96301aeb 100644
--- a/drivers/misc/cros_ec_spi.c
+++ b/drivers/misc/cros_ec_spi.c
@@ -184,8 +184,8 @@ static const struct udevice_id cros_ec_ids[] = {
{ }
};
-U_BOOT_DRIVER(cros_ec_spi) = {
- .name = "cros_ec_spi",
+U_BOOT_DRIVER(google_cros_ec_spi) = {
+ .name = "google_cros_ec_spi",
.id = UCLASS_CROS_EC,
.of_match = cros_ec_ids,
.probe = cros_ec_probe,
--
2.28.0.806.g8561365e88-goog
[PATCH v2] usb: dwc2: Fix contorl OUT transfer issue
In buffer DMA mode, gadget should re-configure EP 0 to received SETUP
packets when doeptsiz.xfersize is equal to a setup packet size(8 bytes)
and EP 0 is in WAIT_FOR_SETUP state.
Since EP 0 is not enabled in WAIT_FOR_SETUP state, SETUP packets is NOT
received from RxFifo and wriiten to the external memory.
Signed-off-by: Chance.Yang
---
Changes for v2:
- fixed 'cast from pointer to integer of different size'
---
drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index 1c0505eb28..136cf5b11b 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -421,6 +421,9 @@ static void process_ep_out_intr(struct dwc2_udc *dev)
{
u32 ep_intr, ep_intr_status;
u8 ep_num = 0;
+ u32 ep_tsr = 0, xfer_size = 0;
+ u32 epsiz_reg = reg->out_endp[ep_num].doeptsiz;
+ u32 req_size = sizeof(struct usb_ctrlrequest);
ep_intr = readl(®->daint);
debug_cond(DEBUG_OUT_EP != 0,
@@ -441,10 +444,17 @@ static void process_ep_out_intr(struct dwc2_udc *dev)
if (ep_num == 0) {
if (ep_intr_status & TRANSFER_DONE) {
- if (dev->ep0state !=
- WAIT_FOR_OUT_COMPLETE)
+ ep_tsr = readl(&epsiz_reg);
+ xfer_size = (ep_tsr &
+ DOEPT_SIZ_XFER_SIZE_MAX_EP0);
+
+ if (xfer_size == req_size &&
+ dev->ep0state == WAIT_FOR_SETUP) {
+ dwc2_udc_pre_setup();
+ } else if (dev->ep0state !=
+ WAIT_FOR_OUT_COMPLETE) {
complete_rx(dev, ep_num);
- else {
+ } else {
dev->ep0state = WAIT_FOR_SETUP;
dwc2_udc_pre_setup();
}
--
2.17.1
Re: [PATCH v2 2/2] checkpatch.pl: Make CONFIG_IS_ENABLED(CONFIG_*) an error
On Mon, 5 Oct 2020 at 00:57, Alper Nebi Yasak wrote: > > CONFIG_IS_ENABLED() takes the kconfig name without the CONFIG_ prefix, > e.g. CONFIG_IS_ENABLED(CLK) for CONFIG_CLK. Make including the prefix > an error in checkpatch.pl so calls in the wrong format aren't > accidentally reintroduced. > > Signed-off-by: Alper Nebi Yasak > --- > > Changes in v2: > - Add patman test > > v1: > https://patchwork.ozlabs.org/project/uboot/patch/20200930114612.22319-2-alpernebiya...@gmail.com/ > > scripts/checkpatch.pl | 6 ++ > tools/patman/test_checkpatch.py | 6 ++ > 2 files changed, 12 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH v2 1/1] log: mute messages generated by log drivers
Hi Heinrich, On Mon, 5 Oct 2020 at 04:42, Heinrich Schuchardt wrote: > > On 05.10.20 12:21, Heinrich Schuchardt wrote: > > When a message is written by a log driver (e.g. via the network stack) this > > may result in the generation of further messages. We cannot allow these > > additional messages to be emitted as this might result in an infinite > > recursion. > > > > Up to now only the syslog driver was safeguarded. We should safeguard all > > log drivers instead. > > > > Signed-off-by: Heinrich Schuchardt > > --- > > This patch is based on > > > > [PATCH v3 0/3] doc: global data pointer > > https://lists.denx.de/pipermail/u-boot/2020-October/428475.html > > > > v2: > > move processing_msg to global data pointer > > (Simon reported a problem with SPL log messages when useing a > > static variable) > > Hello Simon, > > this is what is needed based on origin/master. > > In origin/next the first version of the patch was merged. > > What should I use as basis? I think you need to use -next since that is where we are now. Also, could you add a log_ prefix to your global_data var and perhaps make it a bool? Regards, Simon
Re: [PATCH v2 1/1] log: mute messages generated by log drivers
On 05.10.20 12:21, Heinrich Schuchardt wrote:
> When a message is written by a log driver (e.g. via the network stack) this
> may result in the generation of further messages. We cannot allow these
> additional messages to be emitted as this might result in an infinite
> recursion.
>
> Up to now only the syslog driver was safeguarded. We should safeguard all
> log drivers instead.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> This patch is based on
>
> [PATCH v3 0/3] doc: global data pointer
> https://lists.denx.de/pipermail/u-boot/2020-October/428475.html
>
> v2:
> move processing_msg to global data pointer
> (Simon reported a problem with SPL log messages when useing a
> static variable)
Hello Simon,
this is what is needed based on origin/master.
In origin/next the first version of the patch was merged.
What should I use as basis?
Best regards
Heinrich
> ---
> common/log.c | 12 +++-
> common/log_syslog.c | 8
> include/asm-generic/global_data.h | 8
> 3 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/common/log.c b/common/log.c
> index 734d26de4a..54f2fdeb36 100644
> --- a/common/log.c
> +++ b/common/log.c
> @@ -192,11 +192,21 @@ static int log_dispatch(struct log_rec *rec)
> {
> struct log_device *ldev;
>
> + /*
> + * When a log driver writes messages (e.g. via the network stack) this
> + * may result in further generated messages. We cannot process them here
> + * as this might result in infinite recursion.
> + */
> + if (gd->processing_msg)
> + return 0;
> +
> + /* Emit message */
> + gd->processing_msg = 1;
> list_for_each_entry(ldev, &gd->log_head, sibling_node) {
> if (log_passes_filters(ldev, rec))
> ldev->drv->emit(ldev, rec);
> }
> -
> + gd->processing_msg = 0;
> return 0;
> }
>
> diff --git a/common/log_syslog.c b/common/log_syslog.c
> index 149ff5af31..2ae703fed7 100644
> --- a/common/log_syslog.c
> +++ b/common/log_syslog.c
> @@ -35,16 +35,9 @@ static int log_syslog_emit(struct log_device *ldev, struct
> log_rec *rec)
> char *log_msg;
> int eth_hdr_size;
> struct in_addr bcast_ip;
> - static int processing_msg;
> unsigned int log_level;
> char *log_hostname;
>
> - /* Fend off messages from the network stack while writing a message */
> - if (processing_msg)
> - return 0;
> -
> - processing_msg = 1;
> -
> /* Setup packet buffers */
> net_init();
> /* Disable hardware and put it into the reset state */
> @@ -108,7 +101,6 @@ static int log_syslog_emit(struct log_device *ldev,
> struct log_rec *rec)
> net_send_packet((uchar *)msg, ptr - msg);
>
> out:
> - processing_msg = 0;
> return ret;
> }
>
> diff --git a/include/asm-generic/global_data.h
> b/include/asm-generic/global_data.h
> index ebb740d34f..6bb7f93678 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -363,6 +363,14 @@ struct global_data {
>* &enum log_fmt defines the bits of the bit mask.
>*/
> int log_fmt;
> +
> + /**
> + * @processing_msg: a log message is being processed
> + *
> + * This flag is used to suppress the creation of additional messages
> + * while another message is being processed.
> + */
> + int processing_msg;
> #endif
> #if CONFIG_IS_ENABLED(BLOBLIST)
> /**
> --
> 2.28.0
>
[PATCH v2 1/1] log: mute messages generated by log drivers
When a message is written by a log driver (e.g. via the network stack) this
may result in the generation of further messages. We cannot allow these
additional messages to be emitted as this might result in an infinite
recursion.
Up to now only the syslog driver was safeguarded. We should safeguard all
log drivers instead.
Signed-off-by: Heinrich Schuchardt
---
This patch is based on
[PATCH v3 0/3] doc: global data pointer
https://lists.denx.de/pipermail/u-boot/2020-October/428475.html
v2:
move processing_msg to global data pointer
(Simon reported a problem with SPL log messages when useing a
static variable)
---
common/log.c | 12 +++-
common/log_syslog.c | 8
include/asm-generic/global_data.h | 8
3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/common/log.c b/common/log.c
index 734d26de4a..54f2fdeb36 100644
--- a/common/log.c
+++ b/common/log.c
@@ -192,11 +192,21 @@ static int log_dispatch(struct log_rec *rec)
{
struct log_device *ldev;
+ /*
+* When a log driver writes messages (e.g. via the network stack) this
+* may result in further generated messages. We cannot process them here
+* as this might result in infinite recursion.
+*/
+ if (gd->processing_msg)
+ return 0;
+
+ /* Emit message */
+ gd->processing_msg = 1;
list_for_each_entry(ldev, &gd->log_head, sibling_node) {
if (log_passes_filters(ldev, rec))
ldev->drv->emit(ldev, rec);
}
-
+ gd->processing_msg = 0;
return 0;
}
diff --git a/common/log_syslog.c b/common/log_syslog.c
index 149ff5af31..2ae703fed7 100644
--- a/common/log_syslog.c
+++ b/common/log_syslog.c
@@ -35,16 +35,9 @@ static int log_syslog_emit(struct log_device *ldev, struct
log_rec *rec)
char *log_msg;
int eth_hdr_size;
struct in_addr bcast_ip;
- static int processing_msg;
unsigned int log_level;
char *log_hostname;
- /* Fend off messages from the network stack while writing a message */
- if (processing_msg)
- return 0;
-
- processing_msg = 1;
-
/* Setup packet buffers */
net_init();
/* Disable hardware and put it into the reset state */
@@ -108,7 +101,6 @@ static int log_syslog_emit(struct log_device *ldev, struct
log_rec *rec)
net_send_packet((uchar *)msg, ptr - msg);
out:
- processing_msg = 0;
return ret;
}
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index ebb740d34f..6bb7f93678 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -363,6 +363,14 @@ struct global_data {
* &enum log_fmt defines the bits of the bit mask.
*/
int log_fmt;
+
+ /**
+* @processing_msg: a log message is being processed
+*
+* This flag is used to suppress the creation of additional messages
+* while another message is being processed.
+*/
+ int processing_msg;
#endif
#if CONFIG_IS_ENABLED(BLOBLIST)
/**
--
2.28.0
[PATCH] arm: mvebu: Remove old comments from configs/mvebu_armada-37xx.h file
These comments are relict for old, now removed config options.
So remove these obsoleted comments too.
Signed-off-by: Pali Rohár
---
include/configs/mvebu_armada-37xx.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/configs/mvebu_armada-37xx.h
b/include/configs/mvebu_armada-37xx.h
index 27428d5a0f..0d585606a7 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -17,8 +17,6 @@
#define CONFIG_SYS_BOOTM_LEN SZ_64M /* Increase max gunzip size */
-/* auto boot */
-
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, \
115200, 230400, 460800, 921600 }
@@ -57,11 +55,8 @@
/*
* SPI Flash configuration
*/
-
#define CONFIG_MTD_PARTITIONS /* required for UBI partition support */
-/* Environment in SPI NOR flash */
-
/*
* Ethernet Driver configuration
*/
@@ -70,8 +65,6 @@
#define CONFIG_USB_MAX_CONTROLLER_COUNT (3 + 3)
-/* USB ethernet */
-
/*
* SATA/SCSI/AHCI configuration
*/
--
2.20.1
RE: [EXT] [PATCH 08/16] spi: nsp_fspi: Include device_compat.h
> -Original Message- > From: Sean Anderson > Sent: Monday, October 5, 2020 7:10 AM > To: u-boot@lists.denx.de > Cc: Sean Anderson ; Jagan Teki > ; Kuldeep Singh > Subject: [EXT] [PATCH 08/16] spi: nsp_fspi: Include device_compat.h s/nsp_fspi/nxp_fspi -Kuldeep
[PATCH v2] ARM: stm32: Use firmware property instead of loadables
There shouldn't be a need to use loadables propertyn because u-boot can be
pointed by firmware property. This change should also speedup boot process
because loadables property is list of strings which code is going through.
On the other hand firmware can just point to one image.
Signed-off-by: Michal Simek
---
Changes in v2:
- Also add dhcor
- Fix subject typo
Only done based on grepping the code. Please retest.
---
board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its | 8
board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its
b/board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its
index 905be57dffd7..dfe89bfad67e 100644
--- a/board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its
+++ b/board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its
@@ -39,28 +39,28 @@
config-1 {
/* DT+SoM+board model */
description =
"dh,stm32mp15xx-dhcom-pdk2_somrev0_boardrev0";
- loadables = "uboot";
+ firmware = "uboot";
fdt = "fdt-1";
};
config-2 {
/* DT+SoM+board model */
description =
"dh,stm32mp15xx-dhcom-pdk2_somrev1_boardrev0";
- loadables = "uboot";
+ firmware = "uboot";
fdt = "fdt-1";
};
config-3 {
/* DT+SoM+board model */
description =
"dh,stm32mp15xx-dhcom-drc02_somrev0_boardrev0";
- loadables = "uboot";
+ firmware = "uboot";
fdt = "fdt-2";
};
config-4 {
/* DT+SoM+board model */
description =
"dh,stm32mp15xx-dhcom-drc02_somrev1_boardrev0";
- loadables = "uboot";
+ firmware = "uboot";
fdt = "fdt-2";
};
diff --git a/board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its
b/board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its
index 7419684f5599..0ea10a14972e 100644
--- a/board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its
+++ b/board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its
@@ -31,7 +31,7 @@
config-1 {
/* DT+SoM+board model */
description =
"arrow,stm32mp15xx-avenger96_somrev0_boardrev1";
- loadables = "uboot";
+ firmware = "uboot";
fdt = "fdt-1";
};
--
2.28.0
Re: [PATCH 0/2] Add support for loading images above 4GB
Hi Simon, On 07. 09. 20 15:57, Simon Glass wrote: > Hi Michal, > > On Mon, 7 Sep 2020 at 03:01, Michal Simek wrote: >> >> Hi Simon, >> >> On 07. 09. 20 3:43, Simon Glass wrote: >>> Hi Michal, >>> >>> On Thu, 3 Sep 2020 at 06:30, Michal Simek wrote: Hi, On 03. 09. 20 13:16, Heinrich Schuchardt wrote: > On 9/3/20 1:03 PM, Michal Simek wrote: >> Hi, >> >> We have several use cases where customers want to partition memory by >> putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used >> for >> others CPU in the systems (like R5) or for secure sw. >> Currently there is limitation in SPL to record load/entry addresses in >> 64bit format because they are recorded in 32bit only. >> This series add support for it. >> Patches have been tested on Xilinx ZynqMP zcu102 board in SD bootmode >> with >> images generated by binman. Because u-boot is using >> CONFIG_POSITION_INDEPENDENT it can be put to others 4k aligned addresses >> and there is no real need to build it to certain offset. >> >> Thanks, >> Michal > > Hello Michal, > > does this series require changes to doc/uImage.FIT/source_file_format.txt? I am not changing fit format. I am just changing how SPL records loadables in DT fit-images node. And also series is using FIT functions for reading these properties (at least in this version). >>> >>> Well I think there should be some mention of the 32/64 bit issue added >>> to the FIT docs. How about adding an example with 64-bit addresses? >> >> git grep "fit-images" doc/ >> and output is 0. It means we really don't have any documentation for >> fit-images embed node. >> It means we should create one. >> >> /fit-images are related to loadables property that's why I think make >> sense to document them together. >> >> What about doc/uImage.FIT/howto.txt? > > Sounds good. v2 sent. Thanks, Michal
Re: [PATCH 2/2] spl: fdt: Record load/entry fit-images entries in 64bit format
On 07. 09. 20 15:57, Simon Glass wrote:
> Hi Michal,
>
> On Mon, 7 Sep 2020 at 02:29, Michal Simek wrote:
>>
>>
>>
>> On 07. 09. 20 3:43, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Thu, 3 Sep 2020 at 05:03, Michal Simek wrote:
The commit 9f45aeb93727 ("spl: fit: implement fdt_record_loadable") which
introduced fdt_record_loadable() state there spl_fit.c is not 64bit safe.
Based on my tests on Xilinx ZynqMP zcu102 platform there shouldn't be a
problem to record these addresses in 64bit format.
The patch adds support for systems which need to load images above 4GB.
>>>
>>> But what about 32-bit systems who read this as a 32-bit number?
>>> Perhaps we should write 32-bit if !CONFIG_PHYS_64BIT?
>>
>> The code for reading doesn't really care if value is 32bit or 64bit.
>> The fit_image_get_entry() and fit_image_get_load() read number of cells
>> used and based on that read 32 or 64 bit values.
>
> Sorry I wrote that before looking at the function. The functions
> should have header-file comments that indicate what they do.
kernel-doc format is in common/image-fit.c already.
M
[PATCH v2 2/2] spl: fdt: Record load/entry fit-images entries in 64bit format
The commit 9f45aeb93727 ("spl: fit: implement fdt_record_loadable") which
introduced fdt_record_loadable() state there spl_fit.c is not 64bit safe.
Based on my tests on Xilinx ZynqMP zcu102 platform there shouldn't be a
problem to record these addresses in 64bit format.
The patch adds support for systems which need to load images above 4GB.
Signed-off-by: Michal Simek
---
(no changes since v1)
common/fdt_support.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b8a8768a2147..5ae75df3c658 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -611,14 +611,9 @@ int fdt_record_loadable(void *blob, u32 index, const char
*name,
if (node < 0)
return node;
- /*
-* We record these as 32bit entities, possibly truncating addresses.
-* However, spl_fit.c is not 64bit safe either: i.e. we should not
-* have an issue here.
-*/
- fdt_setprop_u32(blob, node, "load", load_addr);
+ fdt_setprop_u64(blob, node, "load", load_addr);
if (entry_point != -1)
- fdt_setprop_u32(blob, node, "entry", entry_point);
+ fdt_setprop_u64(blob, node, "entry", entry_point);
fdt_setprop_u32(blob, node, "size", size);
if (type)
fdt_setprop_string(blob, node, "type", type);
--
2.28.0
[PATCH v2 0/2] Add support for loading images above 4GB
Hi, We have several use cases where customers want to partition memory by putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for others CPU in the systems (like R5) or for secure sw. Currently there is limitation in SPL to record load/entry addresses in 64bit format because they are recorded in 32bit only. This series add support for it. Patches have been tested on Xilinx ZynqMP zcu102 board in SD bootmode with images generated by binman. Because u-boot is using CONFIG_POSITION_INDEPENDENT it can be put to others 4k aligned addresses and there is no real need to build it to certain offset. Thanks, Michal Changes in v2: - Also fix opensbi - Add record to doc/uImage.FIT/howto.txt - reported by Simon Michal Simek (2): spl: Use standard FIT entries spl: fdt: Record load/entry fit-images entries in 64bit format common/fdt_support.c | 9 + common/spl/spl_atf.c | 7 ++-- common/spl/spl_fit.c | 6 ++- common/spl/spl_opensbi.c | 8 ++-- doc/uImage.FIT/howto.txt | 84 5 files changed, 98 insertions(+), 16 deletions(-) -- 2.28.0
[PATCH v2 1/2] spl: Use standard FIT entries
SPL is creating fit-images DT node when loadables are recorded in selected
configuration. Entries which are created are using entry-point and
load-addr property names. But there shouldn't be a need to use non standard
properties because entry/load are standard FIT properties. But using
standard FIT properties enables option to use generic FIT functions to
descrease SPL size. Here is result for ZynqMP virt configuration:
xilinx_zynqmp_virt: spl/u-boot-spl:all -82 spl/u-boot-spl:rodata -22
spl/u-boot-spl:text -60
The patch causes change in run time fit image record.
Before:
fit-images {
uboot {
os = "u-boot";
type = "firmware";
size = <0xfd520>;
entry-point = <0x800>;
load-addr = <0x800>;
};
};
After:
fit-images {
uboot {
os = "u-boot";
type = "firmware";
size = <0xfd520>;
entry = <0x800>;
load = <0x800>;
};
};
Replacing calling fdt_getprop_u32() by fit_image_get_entry/load() also
enables support for reading entry/load properties recorded in 64bit format.
Signed-off-by: Michal Simek
---
Changes in v2:
- Also fix opensbi
- Add record to doc/uImage.FIT/howto.txt - reported by Simon
Would be good to know history of fit-images and it's property names but
there shouldn't be a need to use non standard names where we have
FIT_*_PROP recorded as macros in include/image.h.
Concern regarding backward compatibility is definitely valid but not sure
how many systems can be affected by this change.
Adding temporary support for entry-point/load-addr is also possible.
Or second way around is to create new wrappers as
fit_image_get_entry_point()/fit_image_get_load_addr() or
call fit_image_get_address() directly.
---
common/fdt_support.c | 4 +-
common/spl/spl_atf.c | 7 ++--
common/spl/spl_fit.c | 6 ++-
common/spl/spl_opensbi.c | 8 ++--
doc/uImage.FIT/howto.txt | 84
5 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index a565b470f81e..b8a8768a2147 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -616,9 +616,9 @@ int fdt_record_loadable(void *blob, u32 index, const char
*name,
* However, spl_fit.c is not 64bit safe either: i.e. we should not
* have an issue here.
*/
- fdt_setprop_u32(blob, node, "load-addr", load_addr);
+ fdt_setprop_u32(blob, node, "load", load_addr);
if (entry_point != -1)
- fdt_setprop_u32(blob, node, "entry-point", entry_point);
+ fdt_setprop_u32(blob, node, "entry", entry_point);
fdt_setprop_u32(blob, node, "size", size);
if (type)
fdt_setprop_string(blob, node, "type", type);
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index b54b4f0d22e2..9bd25f6b32c1 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -132,10 +132,11 @@ static int spl_fit_images_find(void *blob, int os)
uintptr_t spl_fit_images_get_entry(void *blob, int node)
{
ulong val;
+ int ret;
- val = fdt_getprop_u32(blob, node, "entry-point");
- if (val == FDT_ERROR)
- val = fdt_getprop_u32(blob, node, "load-addr");
+ ret = fit_image_get_entry(blob, node, &val);
+ if (ret)
+ ret = fit_image_get_load(blob, node, &val);
debug("%s: entry point 0x%lx\n", __func__, val);
return val;
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 0e27ad1d6a55..aeb8aeda2b19 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -332,9 +332,13 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
}
if (image_info) {
+ ulong entry_point;
+
image_info->load_addr = load_addr;
image_info->size = length;
- image_info->entry_point = fdt_getprop_u32(fit, node, "entry");
+
+ if (!fit_image_get_entry(fit, node, &entry_point))
+ image_info->entry_point = entry_point;
}
return 0;
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index 14f335f75f02..41e0746bb012 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -61,11 +61,9 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
}
/* Get U-Boot entry point */
- uboot_entry = fdt_getprop_u32(spl_image->fdt_addr, uboot_node,
- "entry-point");
- if (uboot_entry == FDT_ERROR)
- uboot_entry = fdt_getprop_u32(spl_image->fdt_addr, uboot_node,
- "load-addr");
+ ret = fit_image_get_entry(spl_image->fdt_addr, uboot_node,
&uboot_entry);
+ if (ret)
+ ret = fit_image_get_load(spl_image->fdt_addr, uboot_node,
&uboo
[PULL] Pull request for u-boot-stm/next = u-boot-stm32-20201003
Hi Tom, Please pull the STM32 related patches for u-boot/next: u-boot-stm32-20201003 With STM32 updates for v2021.01-rc1: - stm32mp: DT alignment with Linux 5.9-rc4 - stm32mp: convert drivers to APIs which support live DT - stm32mp: gpio: minor fixes CI status: https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/4880 Thanks, Patrick git request-pull origin/next https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20201003 The following changes since commit 7e373a1a6ac27492ffebba146d70c4d39a9b9f36: Merge branch 'next' of git://git.denx.de/u-boot-usb into next (2020-10-01 14:52:56 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20201003 for you to fetch changes up to 04e29ca5bbb82f15d7a32d4130214c6a15db69aa: mailbox: stm32_ipcc: Convert to use APIs which support live DT (2020-10-02 15:05:14 +0200) - stm32mp: DT alignment with Linux 5.9-rc4 - stm32mp: convert drivers to APIs which support live DT - stm32mp: gpio: minor fixes Patrick Delaunay (8): ARM: dts: stm32mp1: DT alignment with Linux kernel v5.9-rc4 gpio: stm32: cosmetic: cleanup gpio_stm32_probe gpio: stm32: check result of ofnode_phandle_args pinctrl: stm32: Convert to use APIs which support live DT pinctrl: stm32: Add header with SPDX licence video: stm32_ltdc: Convert to use APIs which support live DT video: stm32_dsi: Convert to use APIs which support live DT mailbox: stm32_ipcc: Convert to use APIs which support live DT arch/arm/dts/stm32mp15-pinctrl.dtsi | 263 +++- arch/arm/dts/stm32mp151.dtsi| 4 +- arch/arm/dts/stm32mp157a-dk1.dts| 2 + arch/arm/dts/stm32mp157c-dk2.dts| 11 arch/arm/dts/stm32mp157c-ed1.dts| 4 +- arch/arm/dts/stm32mp157c-ev1.dts| 15 + arch/arm/dts/stm32mp15xx-dkx.dtsi | 38 - drivers/gpio/stm32_gpio.c | 15 +++-- drivers/mailbox/stm32-ipcc.c| 9 +-- drivers/pinctrl/pinctrl_stm32.c | 48 +--- drivers/video/stm32/stm32_dsi.c | 3 +- drivers/video/stm32/stm32_ltdc.c| 3 +- 12 files changed, 360 insertions(+), 55 deletions(-)
Re: [PATCH v2] ARM: zynq: Add Z-turn board V5
On 01. 10. 20 10:33, agrive...@deutnet.info wrote:
> From: Alexandre GRIVEAUX
>
> Adding Z-turn board V5 to resolve the change between:
>
> "Z-TURNBOARD_schematic.pdf" schematics state version 1 to 4 has Atheros AR8035
> "Z-Turn_Board_sch_V15_20160303.pdf" schematics state version 5 has Micrel
> KSZ9031
>
> At this time the S25FL128SAGNFI003 doesn't work because of bug:
>
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
>
> zynq-zturn was checked on V5 board, same error.
>
> Maybe Z-turn board have the same problem (board with W25Q128BVFIG).
>
> Signed-off-by: Alexandre GRIVEAUX
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/zynq-zturn-common.dtsi | 120
> arch/arm/dts/zynq-zturn-v5.dts| 15 +
> arch/arm/dts/zynq-zturn.dts | 109 +--
> .../xilinx/zynq/zynq-zturn-v5/ps7_init_gpl.c | 273 ++
> configs/xilinx_zynq_virt_defconfig| 4 +-
> 6 files changed, 413 insertions(+), 109 deletions(-)
> create mode 100644 arch/arm/dts/zynq-zturn-common.dtsi
> create mode 100644 arch/arm/dts/zynq-zturn-v5.dts
> create mode 100644 board/xilinx/zynq/zynq-zturn-v5/ps7_init_gpl.c
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f8f529435b..0f8973b1c8 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -277,6 +277,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
> zynq-zc770-xm013.dtb \
> zynq-zed.dtb \
> zynq-zturn.dtb \
> + zynq-zturn-v5.dtb \
> zynq-zybo.dtb \
> zynq-zybo-z7.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += \
> diff --git a/arch/arm/dts/zynq-zturn-common.dtsi
> b/arch/arm/dts/zynq-zturn-common.dtsi
> new file mode 100644
> index 00..1d7af02893
> --- /dev/null
> +++ b/arch/arm/dts/zynq-zturn-common.dtsi
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2015 Andrea Merello
> + * Copyright (C) 2017 Alexander Graf
> + *
> + * Based on zynq-zed.dts which is:
> + * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2012 National Instruments Corp.
> + *
> + */
> +
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> + compatible = "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart1;
> + serial1 = &uart0;
> + mmc0 = &sdhci0;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x4000>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> + usr-led1 {
> + label = "usr-led1";
> + gpios = <&gpio0 0x0 0x1>;
> + default-state = "off";
> + };
> +
> + usr-led2 {
> + label = "usr-led2";
> + gpios = <&gpio0 0x9 0x1>;
> + default-state = "off";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + K1 {
> + label = "K1";
> + gpios = <&gpio0 0x32 0x1>;
> + linux,code = <0x66>;
> + wakeup-source;
> + autorepeat;
> + };
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <>;
> +};
> +
> +&qspi {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy@0 {
> + };
> +};
> +
> +&sdhci0 {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&uart0 {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&uart1 {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> +};
> +
> +&can0 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> + clock-frequency = <40>;
> +
> + stlm75@49 {
> + status = "okay";
> + compatible = "lm75";
> + reg = <0x49>;
> + };
> +
> + accelerometer@53 {
> + compatible = "adi,adxl345", "adxl345", "adi,adxl34x", "adxl34x";
> + reg = <0x53>;
> + interrupt-parent = <&intc>;
> + interrupts = <0x0 0x1e 0x4>;
> + };
> +};
> diff --git a/arch/arm/dts/zynq-zturn-v5.dts b/arch/arm/dts/zynq-zturn-v5.dts
> new file mode 100644
> index 00..536632a09a
> --- /dev/null
> +++ b/arch/arm/dts/zynq-zturn-v5.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +/include/ "zynq-zturn-common.dtsi"
> +
> +/ {
> + model = "Zynq Z-Turn MYIR Board V5";
> + compatible = "myir,zynq-zturn-v5", "xlnx,zynq-7000";
> +};
> +
> +&gem0 {
> + ethernet_phy: ethern
