From patchwork Wed Mar 16 03:03:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Glass X-Patchwork-Id: 1605916 X-Patchwork-Delegate: xypron.glpk@gmx.de Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256 header.s=google header.b=cTq/AeoP; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=85.214.62.61; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KJFV94VMLz9sBy for ; Wed, 16 Mar 2022 14:03:59 +1100 (AEDT) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5AE6483947; Wed, 16 Mar 2022 04:03:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="cTq/AeoP"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 024C183941; Wed, 16 Mar 2022 04:03:45 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.2 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 04B458394C for ; Wed, 16 Mar 2022 04:03:35 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@chromium.org Received: by mail-pf1-x436.google.com with SMTP id t5so2036555pfg.4 for ; Tue, 15 Mar 2022 20:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=MJ0aIQax2MFWeRURUjpQcPu782ZOLWEWYmr4yxsxSs0=; b=cTq/AeoPOp2+OVQI7QKDn2U8qAve5q+T/O170kCRXeHeRIn+vrSwUO5U/tD+yunPAK 3a2F1mI2PiNwBUI69R+kmn5S9kN2fPck4RFMf2KlgzWqFzDyBzoL6jpVNB1FmLLUmNpu zdgBuFCC9RxE4F0wHLQ5EtZC6ZP/5bjc809yg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=MJ0aIQax2MFWeRURUjpQcPu782ZOLWEWYmr4yxsxSs0=; b=ZuG1fv8pb/pS3/6828JkxQDcP+L2BuWIZ/DLPpUPUI9t4AbXdYGO7os6XU+yCp0GOR oAU4V3EslpWV/NdNTwkjNPEhSDvjqw5vPTb2jynS6jhSk94uuWrU2tdSidQPyY2E+ag8 8K1hk/nMCLWOLPBfSL1gDMSnHWGg6Jh58B6iz/nSjl4DcyTOfNgpS0JJGCo7MGxFjcDQ /mVCEZXER5FvESernvpdO1Cx2ecEFQgs65s+EFC+kiYdkxv4z8Py1/mT0REwMfPLmJQ/ FilcPOLYEXWUKacG3/BcY1bIvhFIasG4E0tFNcrfsVPEdtXMEmN6Kw5tEW4sMXRkta6Y nLCA== X-Gm-Message-State: AOAM533EhBW09SRHZp6cC6aL2UNWAvBPIVUzQD6rpq4p+6QbBraPe0S8 G1IbpWofgyHFgoRRp37z8Yi7grqbPuMXIA== X-Google-Smtp-Source: ABdhPJwM2cmQAg9LnQK11a4BRdHN7qtr1CuRkFr+6CP3NEhVfKJU916q9u1uoZtFkOb4Z0ASDz72iw== X-Received: by 2002:a62:fb0f:0:b0:4f2:6d3f:5ffb with SMTP id x15-20020a62fb0f000000b004f26d3f5ffbmr31189085pfm.55.1647399813919; Tue, 15 Mar 2022 20:03:33 -0700 (PDT) Received: from sjg1.roam.corp.google.com ([27.110.126.54]) by smtp.gmail.com with ESMTPSA id y13-20020a056a00180d00b004f733bc57e5sm554199pfa.192.2022.03.15.20.03.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Mar 2022 20:03:31 -0700 (PDT) From: Simon Glass To: U-Boot Mailing List Cc: Tom Rini , Fabio Estevam , Marek Vasut , Soeren Moch , Simon Glass , Pavel Herrmann Subject: [PATCH v2] dm: Add docs to explain how to enable DM_SERIAL for a board Date: Tue, 15 Mar 2022 21:03:20 -0600 Message-Id: <20220316030321.1008573-1-sjg@chromium.org> X-Mailer: git-send-email 2.35.1.723.g4982287a31-goog MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean This is an attempt to cover the common cases found when enabling driver model for serial on a new board. Signed-off-by: Simon Glass Reviewed-by: Fabio Estevam --- Changes in v2: - Add an example patch - Mention removing old code that is not used doc/develop/driver-model/serial-howto.rst | 152 ++++++++++++++++++++++ 1 file changed, 152 insertions(+) diff --git a/doc/develop/driver-model/serial-howto.rst b/doc/develop/driver-model/serial-howto.rst index 1469131124b..e595049c0a3 100644 --- a/doc/develop/driver-model/serial-howto.rst +++ b/doc/develop/driver-model/serial-howto.rst @@ -44,3 +44,155 @@ this involves these steps: - build and get u-boot-dtb.bin so you can test it - Your drivers can now use device tree - For device tree in SPL, define CONFIG_SPL_OF_CONTROL + + +Converting boards to CONFIG_DM_SERIAL +------------------------------------- + +If your SoC has a serial driver that uses driver model (has U_BOOT_DRIVER() in +it) then you may still find that your board has not been converted. To convert +your board, enable the option and see if you can get it working. + +Firstly you will have a lot more success if you have a method of debugging your +board, such as a JTAG connection. Failing that the debug UART is useful, +although since you are trying to get the UART driver running, it will interfere +with your efforts eventually. + +Secondly, while the UART is a relatively simple peripheral, it may need quite a +few pieces to be up and running before it will work, such as the correct pin +muxing, clocks, power domains and possibly even GPIOs, if an external +transceiver is used. Look at other boards that use the same SoC, for clues as to +what is needed. + +Thirdly, when added tags, put them in a xxx-u-boot.dtsi file, where xxx is your +board name, or SoC name. There may already be a file for your SoC which contains +what you need. U-Boot automatically includes these files: see :ref:`dttweaks`. + +Here are some things you might need to consider: + +1. The serial driver itself needs to be present before relocation, so that the +U-Boot banner appears. Make sure it has a u-boot,pre-reloc tag in the device +tree, so that the serial driver is bound when U-Boot starts. + +For example, on iMX8:: + + lpuart3: serial@5a090000 { + compatible = "fsl,imx8qm-lpuart"; + ... + }; + +put this in your xxx-u-boot.dtsi file:: + + &lpuart3 { + u-boot,dm-pre-proper; + }; + +2. If your serial port requires a particular pinmux configuration, you may need +a pinctrl driver. This needs to have a u-boot,pre-reloc tag also. Take care that +any subnodes have the same tag, if they are needed to make the correct pinctrl +available. + +For example, on RK3288, the UART2 uses uart2_xfer:: + + uart2: serial@ff690000 { + ... + pinctrl-0 = <&uart2_xfer>; + }; + +which is defined as follows:: + + pinctrl: pinctrl { + compatible = "rockchip,rk3228-pinctrl"; + + uart2: uart2 { + uart2_xfer: uart2-xfer { + rockchip,pins = <1 RK_PC2 RK_FUNC_2 &pcfg_pull_up>, + <1 RK_PC3 RK_FUNC_2 &pcfg_pull_none>; + }; + + ... + }; + +This means you must make the uart2-xfer node available as well as all its +parents, so put this in your xxx-u-boot.dtsi file:: + + &pinctrl { + u-boot,dm-pre-reloc; + }; + + &uart2 { + u-boot,dm-pre-reloc; + }; + + &uart2_xfer { + u-boot,dm-pre-reloc; + }; + +3. The same applies to power domains. For example, if a particular power domain +must be enabled for the serial port to work, you need to ensure it is available +before relocation: + +For example, on iMX8, put this in your xxx-u-boot.dtsi file:: + + &pd_dma { + u-boot,dm-pre-proper; + }; + + &pd_dma_lpuart3 { + u-boot,dm-pre-proper; + }; + +4. The same applies to clocks, in the same way. Make sure that when your driver +requests a clock, typically with clk_get_by_index(), it is available. + + +Generally a failure to find a required device will cause an error which you can +catch, if you have the debug UART working. U-Boot outputs serial data to the +debug UART until the point where the real serial driver takes over. This point +is marked by gd->flags having the GD_FLG_SERIAL_READY flag set. This change +happens in serial_init() in serial-uclass.c so until that point the debug UART +is used. You can see the relevant code in putc() +, for example:: + + /* if we don't have a console yet, use the debug UART */ + if (IS_ENABLED(CONFIG_DEBUG_UART) && !(gd->flags & GD_FLG_SERIAL_READY)) { + printch(c); + return; + } + ... carries on to use the console / serial driver + +Note that in device_probe() the call to pinctrl_select_state() silently fails +if the pinctrl driver fails. You can add a temporary check there if needed. + +Why do we have all these tags? The problem is that before relocation we don't +want to bind all the drivers since memory is limited and the CPU may be running +at a slow speed. So many boards will fail to boot without this optimisation, or +may take a long time to start up (e.g. hundreds of milliseconds). The tags tell +U-Boot which drivers to bind. + +The good news is that this problem is normally solved by the SoC, so that any +boards that use it will work as normal. But in some cases there are multiple +UARTs or multiple pinmux options, which means that each board may need to do +some customisation. + +Serial in SPL +------------- + +A similar process is needed in SPL, but in this case the u-boot,dm-spl or +u-boot,dm-tpl tags are used. Add these in the same way as above, to ensure that +the SPL device tree contains the required nodes (see spl/u-boot-spl.dtb for +what it actually contains). + +Removing old code +----------------- + +In some cases there may be initialisation code that is no-longer needed when +driver model is used, such as setting up the pin muxing, or enabling a clock. +Be sure to remove this. + +Example patch +------------- + +See this serial_patch_ for iMX7. + +.. _serial_patch: https://patchwork.ozlabs.org/project/uboot/patch/20220314232406.1945308-1-festevam@gmail.com/