Re: [U-Boot] [PATCH v3 021/108] x86: timer: Set up the timer in timer_early_get_count()
On Mon, Oct 28, 2019 at 3:12 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > This function can be called before the timer is set up. Make sure that the > > init function is called so that it works correctly. > > > > This is needed so that bootstage can work correctly in TPL. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Update commit message > > > > Changes in v2: None > > > > drivers/timer/tsc_timer.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 019/108] spl: Add a size check for TPL
On Mon, Oct 28, 2019 at 2:34 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > We have the ability to enforce a maximum size for SPL but not yet for TPL. > > Add a new option for this. > > > > Document the size check macro while we are here. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > Makefile | 7 +++ > > common/spl/Kconfig | 8 > > 2 files changed, 15 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 029/108] x86: Add a CPU init function for TPL
On Mon, Oct 28, 2019 at 3:50 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > > > For TPL we only need to set up the features and identify the CPU to a > > basic level. Add a function to handle that. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > arch/x86/cpu/i386/cpu.c | 8 > > arch/x86/include/asm/u-boot-x86.h | 9 + > > 2 files changed, 17 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 031/108] x86: Don't print CPU info in TPL
On Sat, Nov 2, 2019 at 1:52 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > > > We don't need to do this and it is done (in more detail) in U-Boot proper. > > Drop this to save code space. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > arch/x86/lib/tpl.c | 5 - > > 1 file changed, 5 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 032/108] x86: Quieten TPL's jump_to_image_no_args()
On Sat, Nov 2, 2019 at 1:52 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > > > We already a message indicating that U-Boot is about to jump to SPL, so > > make this one a debug() to reduce code size. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > arch/x86/lib/tpl.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 030/108] x86: Move CPU init to before spl_init()
On Mon, Oct 28, 2019 at 3:52 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > > > At present we call spl_init() before identifying the CPU. This is not a > > good idea - e.g. if bootstage is enabled then it will try to set up the > > timer which works better if the CPU is identified. > > > > Put explicit code at each entry pointer to identify the CPU. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > arch/x86/cpu/start_from_spl.S | 1 + > > arch/x86/lib/spl.c| 4 > > arch/x86/lib/tpl.c| 5 + > > 3 files changed, 10 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Different build result for board "tbs2910" in gitlab-ci and azure
On Sat, Nov 02, 2019 at 09:02:36PM +0800, Bin Meng wrote: > Hi Tom, > > When I build Simon's patches (the one I applied to u-boot-x86 today), > I noticed that the build results for board "tbs2910" in gitlab-ci and > azure are different. > > On gitlab-ci [1], the build fails with error message: > >arm: + tbs2910 > +u-boot.imx exceeds file size limit: > + limit: 0x5fc00 bytes > + actual: 0x60c00 bytes > + excess: 0x1000 bytes > +make[1]: *** [u-boot.imx] Error 1 > +make[1]: *** Deleting file 'u-boot.imx' > +make: *** [sub-make] Error 2 > > 125 3311 /7010:17:40 : tbs2910 > > On azure [2] job "Build the World imx6", the build succeeds: > >arm: w+ tbs2910 > += WARNING == > +This board does not use CONFIG_DM_VIDEO Please update > +the board to use CONFIG_DM_VIDEO before the v2019.07 release. > +Failure to update by the deadline may result in board removal. > +See doc/driver-model/MIGRATION.txt for more info. > + > +CONFIG_OF_EMBED is enabled. This option should only > +be used for debugging purposes. Please use > +CONFIG_OF_SEPARATE for boards in mainline. > +See doc/README.fdt-control for more info. > > 6 240 /55 0:07:44 : tbs2910 > > I am not sure what might be the problem. Do you know what could be the cause? > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/26524 > [2] https://dev.azure.com/bmeng/GitHub/_build/results?buildId=135 I just noticed that as well. I suspect the answer is hard-coded source paths in the binary and it's short enough on GitLab-CI (/build/u-boot/u-boot) and Azure (/u/u-boot/u-boot/ ?) but not Travis. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Sat, Nov 02, 2019 at 04:30:11PM +0200, Vladimir Oltean wrote: > On Sat, 2 Nov 2019 at 16:12, Tom Rini wrote: > > > > On Sat, Nov 02, 2019 at 02:17:28PM +0100, Michael Walle wrote: > > > Am 2019-05-15 16:58, schrieb Tom Rini: > > > > On Fri, May 10, 2019 at 09:50:45PM +, Joe Hershberger wrote: > > > > > Hi Vladimir and Tom, > > > > > > > > > > On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean > > > > > wrote: > > > > > > > > > > > > On 09.05.2019 02:05, Vladimir Oltean wrote: > > > > > > > On 5/9/19 1:55 AM, Tom Rini wrote: > > > > > > >> On Wed, May 08, 2019 at 10:52:28PM +, Vladimir Oltean wrote: > > > > > > >>> On 5/9/19 1:48 AM, Tom Rini wrote: > > > > > > On Wed, May 08, 2019 at 10:45:50PM +, Vladimir Oltean > > > > > > wrote: > > > > > > > On 5/9/19 1:42 AM, Tom Rini wrote: > > > > > > >> On Wed, May 08, 2019 at 10:40:57PM +, Vladimir Oltean > > > > > > >> wrote: > > > > > > >>> On 5/9/19 1:24 AM, Joe Hershberger wrote: > > > > > > On Tue, May 7, 2019 at 5:15 PM Joe Hershberger > > > > > > wrote: > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > The following changes since commit > > > > > > > 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > > > > > > > > > > > > > I rebased on your master and built for BB Black. DHCP > > > > > > > seems to work fine. > > > > > > > MLO also now fits again. > > > > > > > > > > > > > >Merge branch 'master' of > > > > > > > git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400) > > > > > > > > > > > > > > are available in the git repository at: > > > > > > > > > > > > > >git://git.denx.de/u-boot-net.git master > > > > > > > > > > > > > > for you to fetch changes up to > > > > > > > 8d0c6858455e89b089222a08d55ff711681ca011: > > > > > > > > > > > > > >net: phy: micrel: Find Micrel PHY node correctly > > > > > > > (2019-05-07 14:51:55 -0500) > > > > > > > > > > > > > > > > > > > > > Carlo Caione (4): > > > > > > >net: phy: Add generic helpers to access MMD > > > > > > > PHY registers > > > > > > >net: phy: ti: use generic helpers to access > > > > > > > MMD registers > > > > > > >cmd: mdio: Switch to generic helpers when > > > > > > > accessing the registers > > > > > > >net: phy: realtek: Introduce quirk to mark RXC > > > > > > > not stoppable > > > > > > > > > > > > > > James Byrne (2): > > > > > > >net: phy: micrel: Use correct skew values on > > > > > > > KSZ9021 > > > > > > >net: phy: micrel: Find Micrel PHY node > > > > > > > correctly > > > > > > > > > > > > > > Murali Karicheri (2): > > > > > > >ARM: k2g-gp-evm: update to rgmii pinmux > > > > > > > configuration > > > > > > >ARM: k2g-ice: Add pinmux support for rgmii > > > > > > > interface > > > > > > > > > > > > > > Pankaj Bansal (1): > > > > > > >drivers: net: ldpaa_eth: fix resource leak > > > > > > > > > > > > > > Siva Durga Prasad Paladugu (2): > > > > > > >net: phy: Reloc next and prev pointers inside > > > > > > > phy_drivers > > > > > > >net: phy: Fix return value check phy_probe > > > > > > > > > > > > > > Valentin-catalin Neacsu (1): > > > > > > >net: phy: aquantia: Set only autoneg on in > > > > > > > register 4.c441 > > > > > > > > > > > > > > Vladimir Oltean (6): > > > > > > >net: phy: ar803x: Address packet drops at low > > > > > > > traffic rate due to SmartEEE feature > > > > > > >net: phy: ar803x: Make RGMII Tx delays > > > > > > > actually configurable for AR8035 > > > > > > >net: phy: ar803x: Use common functions for > > > > > > > RGMII internal delays > > > > > > >net: phy: ar803x: Clarify the configuration of > > > > > > > the CLK_25M output pin > > > > > > >net: phy: ar803x: Explicitly disable RGMII > > > > > > > delays > > > > > > > > > > > > Tom, this [1] is the patch that is breaking the evm. It > > > > > > doesn't affect > > > > > > BB Black because it uses an SMSC phy, where as this evm > > > > > > uses an > > > > > > AR8031/AR8033. > > > > > > > > > > > > Is it possible the device tree [2] is wrong for the board? > > > > > > It lists > > > > > > 'phy-mode =
Re: [U-Boot] Different build result for board "tbs2910" in gitlab-ci and azure
On Sat, Nov 02, 2019 at 09:17:32PM +0800, Bin Meng wrote: > Hi Tom, > > On Sat, Nov 2, 2019 at 9:05 PM Tom Rini wrote: > > > > On Sat, Nov 02, 2019 at 09:02:36PM +0800, Bin Meng wrote: > > > Hi Tom, > > > > > > When I build Simon's patches (the one I applied to u-boot-x86 today), > > > I noticed that the build results for board "tbs2910" in gitlab-ci and > > > azure are different. > > > > > > On gitlab-ci [1], the build fails with error message: > > > > > >arm: + tbs2910 > > > +u-boot.imx exceeds file size limit: > > > + limit: 0x5fc00 bytes > > > + actual: 0x60c00 bytes > > > + excess: 0x1000 bytes > > > +make[1]: *** [u-boot.imx] Error 1 > > > +make[1]: *** Deleting file 'u-boot.imx' > > > +make: *** [sub-make] Error 2 > > > > > > 125 3311 /7010:17:40 : tbs2910 > > > > > > On azure [2] job "Build the World imx6", the build succeeds: > > > > > >arm: w+ tbs2910 > > > += WARNING == > > > +This board does not use CONFIG_DM_VIDEO Please update > > > +the board to use CONFIG_DM_VIDEO before the v2019.07 release. > > > +Failure to update by the deadline may result in board removal. > > > +See doc/driver-model/MIGRATION.txt for more info. > > > + > > > +CONFIG_OF_EMBED is enabled. This option should only > > > +be used for debugging purposes. Please use > > > +CONFIG_OF_SEPARATE for boards in mainline. > > > +See doc/README.fdt-control for more info. > > > > > > 6 240 /55 0:07:44 : tbs2910 > > > > > > I am not sure what might be the problem. Do you know what could be the > > > cause? > > > > > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/26524 > > > [2] https://dev.azure.com/bmeng/GitHub/_build/results?buildId=135 > > > > I just noticed that as well. I suspect the answer is hard-coded source > > paths in the binary and it's short enough on GitLab-CI > > (/build/u-boot/u-boot) and Azure (/u/u-boot/u-boot/ ?) but not Travis. > > So right now both gitlab-ci and travis fails with this board. Azure is > using /u as the working directory (short enough). GitLab is close? https://gitlab.denx.de/u-boot/u-boot/pipelines/1191 -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Sat, 2 Nov 2019 at 16:12, Tom Rini wrote: > > On Sat, Nov 02, 2019 at 02:17:28PM +0100, Michael Walle wrote: > > Am 2019-05-15 16:58, schrieb Tom Rini: > > > On Fri, May 10, 2019 at 09:50:45PM +, Joe Hershberger wrote: > > > > Hi Vladimir and Tom, > > > > > > > > On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean > > > > wrote: > > > > > > > > > > On 09.05.2019 02:05, Vladimir Oltean wrote: > > > > > > On 5/9/19 1:55 AM, Tom Rini wrote: > > > > > >> On Wed, May 08, 2019 at 10:52:28PM +, Vladimir Oltean wrote: > > > > > >>> On 5/9/19 1:48 AM, Tom Rini wrote: > > > > > On Wed, May 08, 2019 at 10:45:50PM +, Vladimir Oltean wrote: > > > > > > On 5/9/19 1:42 AM, Tom Rini wrote: > > > > > >> On Wed, May 08, 2019 at 10:40:57PM +, Vladimir Oltean > > > > > >> wrote: > > > > > >>> On 5/9/19 1:24 AM, Joe Hershberger wrote: > > > > > On Tue, May 7, 2019 at 5:15 PM Joe Hershberger > > > > > wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > The following changes since commit > > > > > > 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > > > > > > > > > > > I rebased on your master and built for BB Black. DHCP seems > > > > > > to work fine. > > > > > > MLO also now fits again. > > > > > > > > > > > >Merge branch 'master' of git://git.denx.de/u-boot-sh > > > > > > (2019-05-07 09:38:00 -0400) > > > > > > > > > > > > are available in the git repository at: > > > > > > > > > > > >git://git.denx.de/u-boot-net.git master > > > > > > > > > > > > for you to fetch changes up to > > > > > > 8d0c6858455e89b089222a08d55ff711681ca011: > > > > > > > > > > > >net: phy: micrel: Find Micrel PHY node correctly > > > > > > (2019-05-07 14:51:55 -0500) > > > > > > > > > > > > > > > > > > Carlo Caione (4): > > > > > >net: phy: Add generic helpers to access MMD PHY > > > > > > registers > > > > > >net: phy: ti: use generic helpers to access MMD > > > > > > registers > > > > > >cmd: mdio: Switch to generic helpers when > > > > > > accessing the registers > > > > > >net: phy: realtek: Introduce quirk to mark RXC > > > > > > not stoppable > > > > > > > > > > > > James Byrne (2): > > > > > >net: phy: micrel: Use correct skew values on > > > > > > KSZ9021 > > > > > >net: phy: micrel: Find Micrel PHY node correctly > > > > > > > > > > > > Murali Karicheri (2): > > > > > >ARM: k2g-gp-evm: update to rgmii pinmux > > > > > > configuration > > > > > >ARM: k2g-ice: Add pinmux support for rgmii > > > > > > interface > > > > > > > > > > > > Pankaj Bansal (1): > > > > > >drivers: net: ldpaa_eth: fix resource leak > > > > > > > > > > > > Siva Durga Prasad Paladugu (2): > > > > > >net: phy: Reloc next and prev pointers inside > > > > > > phy_drivers > > > > > >net: phy: Fix return value check phy_probe > > > > > > > > > > > > Valentin-catalin Neacsu (1): > > > > > >net: phy: aquantia: Set only autoneg on in > > > > > > register 4.c441 > > > > > > > > > > > > Vladimir Oltean (6): > > > > > >net: phy: ar803x: Address packet drops at low > > > > > > traffic rate due to SmartEEE feature > > > > > >net: phy: ar803x: Make RGMII Tx delays actually > > > > > > configurable for AR8035 > > > > > >net: phy: ar803x: Use common functions for RGMII > > > > > > internal delays > > > > > >net: phy: ar803x: Clarify the configuration of > > > > > > the CLK_25M output pin > > > > > >net: phy: ar803x: Explicitly disable RGMII delays > > > > > > > > > > Tom, this [1] is the patch that is breaking the evm. It > > > > > doesn't affect > > > > > BB Black because it uses an SMSC phy, where as this evm uses > > > > > an > > > > > AR8031/AR8033. > > > > > > > > > > Is it possible the device tree [2] is wrong for the board? > > > > > It lists > > > > > 'phy-mode = "rgmii-txid";', so that means that with this > > > > > patch the RX > > > > > delay is now being disabled. > > > > > > > > > > Any thoughts, Vladimir? > > > > > > > > > > Thanks, > > > > > -Joe > > > > > > > > > > [1] b3224e0f7e - "net: phy: ar803x:
Re: [U-Boot] [PATCH v3 012/108] spl: Correct priority selection for image loaders
On Mon, Oct 28, 2019 at 1:54 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > At present the name of the image comes first in the linker-list symbol > > used. This means that the name of the function sets the sort order, which > > is not the intention. > > > > Update it to put the boot-device type first, then the priority. This > > produces the expected behaviour. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: > > - s/board device/boot device/ > > > > include/spl.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 004/108] binman: Fix up comment in intel-fsp-m
On Mon, Oct 28, 2019 at 11:27 AM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > This comment references the wrong FSP component. Fix it. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > tools/binman/etype/intel_fsp_m.py | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 006/108] dm: gpio: Allow control of GPIO uclass in SPL
On Mon, Oct 28, 2019 at 12:45 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass > > is included in SPL/TPL without any control for boards. Some boards may > > want to disable this to reduce code size where GPIOs are not needed in > > SPL or TPL. > > > > Add a new Kconfig option to permit this. Default it to 'y' so that > > existing boards work correctly. > > > > Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to > > preserve the current behaviour. Also update the 74x164 GPIO driver since > > it cannot build with SPL. > > > > This allows us to remove the hacks in config_uncmd_spl.h and > > Makefile.uncmd_spl (eventually those files should be removed). > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: > > - Fix the Kconfig condition to avoid build errors on snow > > > > arch/arm/include/asm/omap_gpio.h | 2 +- > > arch/arm/mach-at91/include/mach/at91sam9260.h | 2 +- > > arch/arm/mach-davinci/include/mach/gpio.h | 2 +- > > arch/arm/mach-omap2/am33xx/board.c| 4 ++-- > > arch/arm/mach-omap2/omap3/board.c | 2 +- > > arch/arm/mach-omap2/omap5/hwinit.c| 2 +- > > board/freescale/imx8qm_mek/imx8qm_mek.c | 2 +- > > board/freescale/imx8qxp_mek/imx8qxp_mek.c | 2 +- > > board/gateworks/gw_ventana/Kconfig| 3 +++ > > board/toradex/apalis-imx8/apalis-imx8.c | 2 +- > > drivers/gpio/Kconfig | 22 +++ > > drivers/gpio/Makefile | 4 +++- > > drivers/gpio/at91_gpio.c | 6 ++--- > > drivers/gpio/atmel_pio4.c | 2 +- > > drivers/gpio/da8xx_gpio.c | 6 ++--- > > drivers/gpio/da8xx_gpio.h | 2 +- > > drivers/gpio/mxc_gpio.c | 4 ++-- > > drivers/gpio/mxs_gpio.c | 4 ++-- > > drivers/gpio/omap_gpio.c | 6 ++--- > > drivers/gpio/sunxi_gpio.c | 8 +++ > > drivers/i2c/i2c-uclass.c | 6 ++--- > > drivers/i2c/muxes/pca954x.c | 4 ++-- > > drivers/mmc/fsl_esdhc_imx.c | 13 ++- > > drivers/mmc/omap_hsmmc.c | 2 +- > > drivers/net/designware.c | 10 - > > drivers/net/designware.h | 4 ++-- > > drivers/net/fec_mxc.c | 6 ++--- > > drivers/net/fec_mxc.h | 2 +- > > drivers/net/mvneta.c | 4 ++-- > > drivers/net/mvpp2.c | 8 +++ > > drivers/net/sun8i_emac.c | 12 +- > > drivers/pci/pci-aardvark.c| 4 ++-- > > drivers/pci/pcie_dw_mvebu.c | 4 ++-- > > drivers/spi/atmel_spi.c | 10 - > > drivers/spi/designware_spi.c | 4 ++-- > > drivers/tpm/tpm2_tis_spi.c| 2 +- > > include/config_uncmd_spl.h| 1 - > > include/configs/at91-sama5_common.h | 5 +++-- > > include/configs/gw_ventana.h | 1 - > > include/configs/mx6ul_14x14_evk.h | 1 + > > scripts/Makefile.uncmd_spl| 1 - > > 41 files changed, 109 insertions(+), 82 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 024/108] x86: spl: Support init of a PUNIT
On Mon, Oct 28, 2019 at 3:12 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > > > The x86 power unit handles power management. Support initing this device > > which is modelled as a new type of system controller since there are no > > operations needed. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Fix 'err-%d' typo > > > > Changes in v2: None > > > > arch/x86/include/asm/cpu.h | 1 + > > arch/x86/lib/spl.c | 40 ++ > > 2 files changed, 41 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 025/108] x86: tpl: Add a fake PCI bus
On Mon, Oct 28, 2019 at 3:12 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > > > In TPL we try to minimise code size so do not include the PCI subsystem. > > We can use fixed BARs and drivers can directly program the devices that > > they need. > > > > However we do need to bind the devices on the PCI bus and without PCI this > > does not ordinarily happen. As a work-around, define a fake PCI bus which > > does this binding, but no other PCI operations. This is a convenient way > > to ensure that we can use the same device tree for TPL, SPL and U-Boot > > proper: > > > >TPL- CONFIG_TPL_PCI is not set (no auto-config, fake PCI bus) > >SPL- CONFIG_SPL_PCI is set (no auto-config but with real PCI bus) > >U-Boot - CONFIG_PCI is set (full auto-config after relocation) > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Fix 'autoallocation' typo > > - Improve wording in commit message > > > > Changes in v2: None > > > > arch/x86/lib/tpl.c | 25 + > > 1 file changed, 25 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 022/108] x86: timer: Use a separate flag for whether timer is inited
On Mon, Oct 28, 2019 at 3:12 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:39 AM Simon Glass wrote: > > > > At present the value of the timer base is used to determine whether the > > timer has been set up or not. It is true that the timer is essentially > > never exactly 0 when it is read. However 'time 0' may indicate the time > > that the machine was reset so it is useful to be able to denote that. > > > > Update the code to use a separate flag instead. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > arch/x86/include/asm/global_data.h | 1 + > > drivers/timer/tsc_timer.c | 3 ++- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Rename roc-rk3399-pc -> roc-pc-rk3399 defconfig
On Sat, Nov 02, 2019 at 10:19:02AM +0530, Jagan Teki wrote:
> roc-rk3399-pc_defconfig is committed in below
>
> commit <8a681f4c5aa15db51ad0209734859c9fe7c29cfd> ("rockchip: rk3399:
> Add ROC-RK3399-PC support")
>
> which doesn't follow the existing defconfigs on rk3399.
>
> So, rename as followed with other rk3399 defconfigs.
>
> Cc: Levin Du
> Signed-off-by: Jagan Teki
> ---
This strikes me as wrong, as the existing name is the actual name of the
board.
https://libre.computer/products/boards/roc-rk3399-pc/
Jonathan Kollasch
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Sat, Nov 02, 2019 at 02:17:28PM +0100, Michael Walle wrote: > Am 2019-05-15 16:58, schrieb Tom Rini: > > On Fri, May 10, 2019 at 09:50:45PM +, Joe Hershberger wrote: > > > Hi Vladimir and Tom, > > > > > > On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean > > > wrote: > > > > > > > > On 09.05.2019 02:05, Vladimir Oltean wrote: > > > > > On 5/9/19 1:55 AM, Tom Rini wrote: > > > > >> On Wed, May 08, 2019 at 10:52:28PM +, Vladimir Oltean wrote: > > > > >>> On 5/9/19 1:48 AM, Tom Rini wrote: > > > > On Wed, May 08, 2019 at 10:45:50PM +, Vladimir Oltean wrote: > > > > > On 5/9/19 1:42 AM, Tom Rini wrote: > > > > >> On Wed, May 08, 2019 at 10:40:57PM +, Vladimir Oltean wrote: > > > > >>> On 5/9/19 1:24 AM, Joe Hershberger wrote: > > > > On Tue, May 7, 2019 at 5:15 PM Joe Hershberger > > > > wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > The following changes since commit > > > > > 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > > > > > > > > > I rebased on your master and built for BB Black. DHCP seems > > > > > to work fine. > > > > > MLO also now fits again. > > > > > > > > > >Merge branch 'master' of git://git.denx.de/u-boot-sh > > > > > (2019-05-07 09:38:00 -0400) > > > > > > > > > > are available in the git repository at: > > > > > > > > > >git://git.denx.de/u-boot-net.git master > > > > > > > > > > for you to fetch changes up to > > > > > 8d0c6858455e89b089222a08d55ff711681ca011: > > > > > > > > > >net: phy: micrel: Find Micrel PHY node correctly > > > > > (2019-05-07 14:51:55 -0500) > > > > > > > > > > > > > > > Carlo Caione (4): > > > > >net: phy: Add generic helpers to access MMD PHY > > > > > registers > > > > >net: phy: ti: use generic helpers to access MMD > > > > > registers > > > > >cmd: mdio: Switch to generic helpers when > > > > > accessing the registers > > > > >net: phy: realtek: Introduce quirk to mark RXC not > > > > > stoppable > > > > > > > > > > James Byrne (2): > > > > >net: phy: micrel: Use correct skew values on > > > > > KSZ9021 > > > > >net: phy: micrel: Find Micrel PHY node correctly > > > > > > > > > > Murali Karicheri (2): > > > > >ARM: k2g-gp-evm: update to rgmii pinmux > > > > > configuration > > > > >ARM: k2g-ice: Add pinmux support for rgmii > > > > > interface > > > > > > > > > > Pankaj Bansal (1): > > > > >drivers: net: ldpaa_eth: fix resource leak > > > > > > > > > > Siva Durga Prasad Paladugu (2): > > > > >net: phy: Reloc next and prev pointers inside > > > > > phy_drivers > > > > >net: phy: Fix return value check phy_probe > > > > > > > > > > Valentin-catalin Neacsu (1): > > > > >net: phy: aquantia: Set only autoneg on in > > > > > register 4.c441 > > > > > > > > > > Vladimir Oltean (6): > > > > >net: phy: ar803x: Address packet drops at low > > > > > traffic rate due to SmartEEE feature > > > > >net: phy: ar803x: Make RGMII Tx delays actually > > > > > configurable for AR8035 > > > > >net: phy: ar803x: Use common functions for RGMII > > > > > internal delays > > > > >net: phy: ar803x: Clarify the configuration of the > > > > > CLK_25M output pin > > > > >net: phy: ar803x: Explicitly disable RGMII delays > > > > > > > > Tom, this [1] is the patch that is breaking the evm. It > > > > doesn't affect > > > > BB Black because it uses an SMSC phy, where as this evm uses an > > > > AR8031/AR8033. > > > > > > > > Is it possible the device tree [2] is wrong for the board? It > > > > lists > > > > 'phy-mode = "rgmii-txid";', so that means that with this patch > > > > the RX > > > > delay is now being disabled. > > > > > > > > Any thoughts, Vladimir? > > > > > > > > Thanks, > > > > -Joe > > > > > > > > [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII > > > > delays" > > > > [2] arch/arm/dts/am335x-evm.dts > > > > > > > > >net: phy: ar803x: Clarify the intention of > > > > > ar8021_config > > > > > > > > > > arch/arm/dts/sama5d3xcm.dtsi
Re: [U-Boot] [PATCH v3 015/108] dm: doc: Correct of-platdata driver name
On Mon, Oct 28, 2019 at 1:59 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > Add a note about the driver name in the of-platdata documentation since > > the naming must follow the compatible string. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Rework patch now that the original CONFIG_IS_ENABLED() problems is fixed > > > > Changes in v2: None > > > > doc/driver-model/of-plat.rst | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 014/108] spi: Add support for memory-mapped flash
On Sat, Nov 2, 2019 at 12:13 PM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > On x86 platforms the SPI flash can be mapped into memory so that the > > contents can be read with normal memory accesses. > > > > Add a new SPI method to find the location of the SPI flash in memory. This > > differs from the existing device-tree "memory-map" mechanism in that the > > location can be discovered at run-time. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Move the get_mmap() method from the SPI_FLASH to the SPI uclass > > > > Changes in v2: None > > > > drivers/spi/sandbox_spi.c | 11 +++ > > drivers/spi/spi-uclass.c | 14 ++ > > include/spi.h | 27 +++ > > test/dm/sf.c | 9 + > > 4 files changed, 61 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Different build result for board "tbs2910" in gitlab-ci and azure
Hi Tom, When I build Simon's patches (the one I applied to u-boot-x86 today), I noticed that the build results for board "tbs2910" in gitlab-ci and azure are different. On gitlab-ci [1], the build fails with error message: arm: + tbs2910 +u-boot.imx exceeds file size limit: + limit: 0x5fc00 bytes + actual: 0x60c00 bytes + excess: 0x1000 bytes +make[1]: *** [u-boot.imx] Error 1 +make[1]: *** Deleting file 'u-boot.imx' +make: *** [sub-make] Error 2 125 3311 /7010:17:40 : tbs2910 On azure [2] job "Build the World imx6", the build succeeds: arm: w+ tbs2910 += WARNING == +This board does not use CONFIG_DM_VIDEO Please update +the board to use CONFIG_DM_VIDEO before the v2019.07 release. +Failure to update by the deadline may result in board removal. +See doc/driver-model/MIGRATION.txt for more info. + +CONFIG_OF_EMBED is enabled. This option should only +be used for debugging purposes. Please use +CONFIG_OF_SEPARATE for boards in mainline. +See doc/README.fdt-control for more info. 6 240 /55 0:07:44 : tbs2910 I am not sure what might be the problem. Do you know what could be the cause? [1] https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/26524 [2] https://dev.azure.com/bmeng/GitHub/_build/results?buildId=135 Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
Am 2019-05-15 16:58, schrieb Tom Rini: On Fri, May 10, 2019 at 09:50:45PM +, Joe Hershberger wrote: Hi Vladimir and Tom, On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean wrote: > > On 09.05.2019 02:05, Vladimir Oltean wrote: > > On 5/9/19 1:55 AM, Tom Rini wrote: > >> On Wed, May 08, 2019 at 10:52:28PM +, Vladimir Oltean wrote: > >>> On 5/9/19 1:48 AM, Tom Rini wrote: > On Wed, May 08, 2019 at 10:45:50PM +, Vladimir Oltean wrote: > > On 5/9/19 1:42 AM, Tom Rini wrote: > >> On Wed, May 08, 2019 at 10:40:57PM +, Vladimir Oltean wrote: > >>> On 5/9/19 1:24 AM, Joe Hershberger wrote: > On Tue, May 7, 2019 at 5:15 PM Joe Hershberger wrote: > > > > Hi Tom, > > > > The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > > > I rebased on your master and built for BB Black. DHCP seems to work fine. > > MLO also now fits again. > > > >Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400) > > > > are available in the git repository at: > > > >git://git.denx.de/u-boot-net.git master > > > > for you to fetch changes up to 8d0c6858455e89b089222a08d55ff711681ca011: > > > >net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 14:51:55 -0500) > > > > > > Carlo Caione (4): > >net: phy: Add generic helpers to access MMD PHY registers > >net: phy: ti: use generic helpers to access MMD registers > >cmd: mdio: Switch to generic helpers when accessing the registers > >net: phy: realtek: Introduce quirk to mark RXC not stoppable > > > > James Byrne (2): > >net: phy: micrel: Use correct skew values on KSZ9021 > >net: phy: micrel: Find Micrel PHY node correctly > > > > Murali Karicheri (2): > >ARM: k2g-gp-evm: update to rgmii pinmux configuration > >ARM: k2g-ice: Add pinmux support for rgmii interface > > > > Pankaj Bansal (1): > >drivers: net: ldpaa_eth: fix resource leak > > > > Siva Durga Prasad Paladugu (2): > >net: phy: Reloc next and prev pointers inside phy_drivers > >net: phy: Fix return value check phy_probe > > > > Valentin-catalin Neacsu (1): > >net: phy: aquantia: Set only autoneg on in register 4.c441 > > > > Vladimir Oltean (6): > >net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature > >net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035 > >net: phy: ar803x: Use common functions for RGMII internal delays > >net: phy: ar803x: Clarify the configuration of the CLK_25M output pin > >net: phy: ar803x: Explicitly disable RGMII delays > > Tom, this [1] is the patch that is breaking the evm. It doesn't affect > BB Black because it uses an SMSC phy, where as this evm uses an > AR8031/AR8033. > > Is it possible the device tree [2] is wrong for the board? It lists > 'phy-mode = "rgmii-txid";', so that means that with this patch the RX > delay is now being disabled. > > Any thoughts, Vladimir? > > Thanks, > -Joe > > [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays" > [2] arch/arm/dts/am335x-evm.dts > > >net: phy: ar803x: Clarify the intention of ar8021_config > > > > arch/arm/dts/sama5d3xcm.dtsi| 32 +++--- > > arch/arm/dts/sama5d3xcm_cmp.dtsi| 32 +++--- > > arch/arm/dts/socfpga_arria5_socdk.dts | 4 +- > > arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +- > > arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +- > > arch/arm/dts/socfpga_cyclone5_sockit.dts| 4 +- > > arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +- > > board/ti/ks2_evm/mux-k2g.h | 36 +++ > > cmd/mdio.c | 27 +++-- > > doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 + > > drivers/net/ldpaa_eth/ldpaa_eth.c | 1 + > > drivers/net/phy/Kconfig | 41 > > drivers/net/phy/aquantia.c | 7 +- > > drivers/net/phy/atheros.c
Re: [U-Boot] Different build result for board "tbs2910" in gitlab-ci and azure
Hi Tom, On Sat, Nov 2, 2019 at 9:05 PM Tom Rini wrote: > > On Sat, Nov 02, 2019 at 09:02:36PM +0800, Bin Meng wrote: > > Hi Tom, > > > > When I build Simon's patches (the one I applied to u-boot-x86 today), > > I noticed that the build results for board "tbs2910" in gitlab-ci and > > azure are different. > > > > On gitlab-ci [1], the build fails with error message: > > > >arm: + tbs2910 > > +u-boot.imx exceeds file size limit: > > + limit: 0x5fc00 bytes > > + actual: 0x60c00 bytes > > + excess: 0x1000 bytes > > +make[1]: *** [u-boot.imx] Error 1 > > +make[1]: *** Deleting file 'u-boot.imx' > > +make: *** [sub-make] Error 2 > > > > 125 3311 /7010:17:40 : tbs2910 > > > > On azure [2] job "Build the World imx6", the build succeeds: > > > >arm: w+ tbs2910 > > += WARNING == > > +This board does not use CONFIG_DM_VIDEO Please update > > +the board to use CONFIG_DM_VIDEO before the v2019.07 release. > > +Failure to update by the deadline may result in board removal. > > +See doc/driver-model/MIGRATION.txt for more info. > > + > > +CONFIG_OF_EMBED is enabled. This option should only > > +be used for debugging purposes. Please use > > +CONFIG_OF_SEPARATE for boards in mainline. > > +See doc/README.fdt-control for more info. > > > > 6 240 /55 0:07:44 : tbs2910 > > > > I am not sure what might be the problem. Do you know what could be the > > cause? > > > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/26524 > > [2] https://dev.azure.com/bmeng/GitHub/_build/results?buildId=135 > > I just noticed that as well. I suspect the answer is hard-coded source > paths in the binary and it's short enough on GitLab-CI > (/build/u-boot/u-boot) and Azure (/u/u-boot/u-boot/ ?) but not Travis. So right now both gitlab-ci and travis fails with this board. Azure is using /u as the working directory (short enough). Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/7] x86: coral: Add support for Cr50
This series adds a driver for the Cr50 security chip and enables it on coral. This supports the 'tpm' command. This series is built on the pending 'apollolake' series. Simon Glass (7): coral: Update i2c and rtc status tpm: Add more TPM2 definitions tpm: Add a driver for H1/Cr50 pci: i2c: designware: Add compatible string coral: Add I2C and TPM device-tree definitions i2c: designware: Drop invalid debugging x86: coral: Enable TPM arch/x86/dts/chromebook_coral.dts | 25 ++ configs/chromebook_coral_defconfig| 5 +- doc/board/google/chromebook_coral.rst | 2 - drivers/i2c/designware_i2c.c | 1 - drivers/i2c/dw_i2c_pci.c | 6 + drivers/tpm/Kconfig | 10 + drivers/tpm/Makefile | 1 + drivers/tpm/cr50_i2c.c| 568 ++ include/tpm-v2.h | 31 ++ 9 files changed, 643 insertions(+), 6 deletions(-) create mode 100644 drivers/tpm/cr50_i2c.c -- 2.24.0.rc1.363.gb1bccd3e3d-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/7] tpm: Add a driver for H1/Cr50
H1 is a Google security chip present in recent Chromebooks, Pixel phones
and other devices. Cr50 is the name of the software that runs on H1 in
Chromebooks.
This chip is used to handle TPM-like functionality and also has quite a
few additional features.
Add a driver for this.
Signed-off-by: Simon Glass
---
drivers/tpm/Kconfig| 10 +
drivers/tpm/Makefile | 1 +
drivers/tpm/cr50_i2c.c | 568 +
3 files changed, 579 insertions(+)
create mode 100644 drivers/tpm/cr50_i2c.c
diff --git a/drivers/tpm/Kconfig b/drivers/tpm/Kconfig
index 94629dffd2..00d7dc8e48 100644
--- a/drivers/tpm/Kconfig
+++ b/drivers/tpm/Kconfig
@@ -127,6 +127,16 @@ config TPM_V2
if TPM_V2
+config TPM2_CR50_I2C
+ bool "Enable support for Google cr50 TPM"
+ depends on DM_I2C
+ help
+ Cr50 is an implementation of a TPM on Google's H1 security chip.
+ This uses the same open-source firmware as the Chromium OS EC.
+ While Cr50 has other features, its primary role is as the root of
+ trust for a devuce, It operates like a TPM and can be used with
+ verified boot. Cr50 is used on recent Chromebooks (since 2017).
+
config TPM2_TIS_SANDBOX
bool "Enable sandbox TPMv2.x driver"
depends on TPM_V2 && SANDBOX
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index 94c337b8ed..4c866b37c5 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_TPM_TIS_SANDBOX) += tpm_tis_sandbox.o
obj-$(CONFIG_TPM_ST33ZP24_I2C) += tpm_tis_st33zp24_i2c.o
obj-$(CONFIG_TPM_ST33ZP24_SPI) += tpm_tis_st33zp24_spi.o
+obj-$(CONFIG_TPM2_CR50_I2C) += cr50_i2c.o
obj-$(CONFIG_TPM2_TIS_SANDBOX) += tpm2_tis_sandbox.o
obj-$(CONFIG_TPM2_TIS_SPI) += tpm2_tis_spi.o
diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
new file mode 100644
index 00..5328c102f6
--- /dev/null
+++ b/drivers/tpm/cr50_i2c.c
@@ -0,0 +1,568 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cr50 / H1 TPM support
+ *
+ * Copyright 2018 Google LLC
+ */
+
+#define LOG_CATEGORY UCLASS_TPM
+#define LOG_DEBUG
+
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ TIMEOUT_LONG_US = 2 * 1000 * 1000,
+ TIMEOUT_SHORT_US= 2 * 1000,
+ TIMEOUT_NO_IRQ_US = 20 * 1000,
+ TIMEOUT_IRQ_US = 100 * 1000,
+};
+
+enum {
+ CR50_DID_VID = 0x00281ae0L
+};
+
+enum {
+ CR50_MAX_BUF_SIZE = 63,
+};
+
+struct cr50_priv {
+ struct gpio_desc ready_gpio;
+ int locality;
+ uint vendor;
+};
+
+/* Wait for interrupt to indicate TPM is ready */
+static int cr50_i2c_wait_tpm_ready(struct udevice *dev)
+{
+ struct cr50_priv *priv = dev_get_priv(dev);
+ ulong timeout;
+ int i;
+
+ if (!dm_gpio_is_valid(>ready_gpio)) {
+ /* Fixed delay if interrupt not supported */
+ udelay(TIMEOUT_NO_IRQ_US);
+ return 0;
+ }
+
+ timeout = timer_get_us() + TIMEOUT_IRQ_US;
+
+ i = 0;
+ while (!dm_gpio_get_value(>ready_gpio)) {
+ i++;
+ if (timer_get_us() > timeout) {
+ printf("Timeout\n");
+ /*
+* Use this instead of -ETIMEDOUT which is used by i2c
+*/
+ return -ETIME;
+ }
+ }
+
+ return 0;
+}
+
+/* Clear pending interrupts */
+static void cr50_i2c_clear_tpm_irq(struct udevice *dev)
+{
+ /* This is not really an interrupt, just a GPIO, so we can't clear it */
+}
+
+/*
+ * cr50_i2c_read() - read from TPM register
+ *
+ * @tpm: TPM chip information
+ * @addr: register address to read from
+ * @buffer: provided by caller
+ * @len: number of bytes to read
+ *
+ * 1) send register address byte 'addr' to the TPM
+ * 2) wait for TPM to indicate it is ready
+ * 3) read 'len' bytes of TPM response into the provided 'buffer'
+ *
+ * Return 0 on success. -ve on error
+ */
+static int cr50_i2c_read(struct udevice *dev, u8 addr, u8 *buffer,
+size_t len)
+{
+ int ret;
+
+ /* Clear interrupt before starting transaction */
+ cr50_i2c_clear_tpm_irq(dev);
+
+ /* Send the register address byte to the TPM */
+ ret = dm_i2c_write(dev, 0, , 1);
+ if (ret) {
+ log_err("Address write failed (err=%d)\n", ret);
+ return ret;
+ }
+
+ /* Wait for TPM to be ready with response data */
+ ret = cr50_i2c_wait_tpm_ready(dev);
+ if (ret)
+ return ret;
+
+ /* Read response data frrom the TPM */
+ ret = dm_i2c_read(dev, 0, buffer, len);
+ if (ret) {
+ log_err("Read response failed (err=%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * cr50_i2c_write() - write to TPM register
+ *
+ * @tpm: TPM chip information
+ * @addr: register address to write to
+ * @buffer: data to
[U-Boot] [PATCH 2/7] tpm: Add more TPM2 definitions
Add definitions for access and status.
Need to drop the mixed case.
Signed-off-by: Simon Glass
---
include/tpm-v2.h | 31 +++
1 file changed, 31 insertions(+)
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index ae00803f6d..d53d2e4023 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -161,6 +161,37 @@ enum tpm_index_attrs {
TPMA_NV_AUTHWRITE | TPMA_NV_POLICYWRITE,
};
+enum {
+ TPM_ACCESS_VALID= 1 << 7,
+ TPM_ACCESS_ACTIVE_LOCALITY = 1 << 5,
+ TPM_ACCESS_REQUEST_PENDING = 1 << 2,
+ TPM_ACCESS_REQUEST_USE = 1 << 1,
+ TPM_ACCESS_ESTABLISHMENT= 1 << 0,
+};
+
+enum {
+ TPM_STS_FAMILY_SHIFT= 26,
+ TPM_STS_FAMILY_MASK = 0x3 << TPM_STS_FAMILY_SHIFT,
+ TPM_STS_FAMILY_TPM2 = 1 << TPM_STS_FAMILY_SHIFT,
+ TPM_STS_RESE_TESTABLISMENT_BIT = 1 << 25,
+ TPM_STS_COMMAND_CANCEL = 1 << 24,
+ TPM_STS_BURST_COUNT_SHIFT = 8,
+ TPM_STS_BURST_COUNT_MASK= 0x << TPM_STS_BURST_COUNT_SHIFT,
+ TPM_STS_VALID = 1 << 7,
+ TPM_STS_COMMAND_READY = 1 << 6,
+ TPM_STS_GO = 1 << 5,
+ TPM_STS_DATA_AVAIL = 1 << 4,
+ TPM_STS_DATA_EXPECT = 1 << 3,
+ TPM_STS_SELF_TEST_DONE = 1 << 2,
+ TPM_STS_RESPONSE_RETRY = 1 << 1,
+};
+
+enum {
+ TPM_CMD_COUNT_OFFSET= 2,
+ TPM_CMD_ORDINAL_OFFSET = 6,
+ TPM_MAX_BUF_SIZE= 1260,
+};
+
/**
* Issue a TPM2_Startup command.
*
--
2.24.0.rc1.363.gb1bccd3e3d-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/7] x86: coral: Enable TPM
Enable TPM2 so that we can use cr50. Signed-off-by: Simon Glass --- configs/chromebook_coral_defconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/configs/chromebook_coral_defconfig b/configs/chromebook_coral_defconfig index 6b586ef3c7..43fb94458b 100644 --- a/configs/chromebook_coral_defconfig +++ b/configs/chromebook_coral_defconfig @@ -53,7 +53,6 @@ CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y CONFIG_CMD_BOOTSTAGE=y CONFIG_CMD_TPM=y -CONFIG_CMD_TPM_TEST=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y @@ -76,7 +75,6 @@ CONFIG_SYS_I2C_DW=y CONFIG_TPL_MISC=y CONFIG_CROS_EC=y CONFIG_CROS_EC_LPC=y -CONFIG_SPI_FLASH_INTEL_FAST=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_X86_PCH7 is not set # CONFIG_X86_PCH9 is not set @@ -89,7 +87,8 @@ CONFIG_SPI=y CONFIG_ICH_SPI=y CONFIG_TPL_SYSRESET=y CONFIG_X86_TSC_ZERO_BASE=y -CONFIG_TPM_TIS_LPC=y +# CONFIG_TPM_V1 is not set +CONFIG_TPM2_CR50_I2C=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_STORAGE=y CONFIG_USB_KEYBOARD=y -- 2.24.0.rc1.363.gb1bccd3e3d-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/7] coral: Update i2c and rtc status
These are actually working correctly, so update the status. Signed-off-by: Simon Glass --- doc/board/google/chromebook_coral.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/doc/board/google/chromebook_coral.rst b/doc/board/google/chromebook_coral.rst index c583ac2b27..b010cc1ded 100644 --- a/doc/board/google/chromebook_coral.rst +++ b/doc/board/google/chromebook_coral.rst @@ -208,9 +208,7 @@ To do - left-side USB - USB-C - Cr50 (security chip: a basic driver is running but not included here) - - I2C (driver exists but not enabled in device tree) - Sound (Intel I2S support exists, but need da7219 driver) - - RTC (driver exists but not enabled in device tree) - Various minor features supported by LPC, etc. - Booting Chrome OS, e.g. with verified boot - Integrate with Chrome OS vboot -- 2.24.0.rc1.363.gb1bccd3e3d-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/7] coral: Add I2C and TPM device-tree definitions
Add a node to the device tree for Cr50. We want this to be on i2c port 2
so add 0 and 1 as well to make this work.
Signed-off-by: Simon Glass
---
arch/x86/dts/chromebook_coral.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/x86/dts/chromebook_coral.dts
b/arch/x86/dts/chromebook_coral.dts
index 79b3e60db4..1e6e0e182f 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -28,6 +28,9 @@
cros-ec0 = _ec;
fsp = _s;
spi0 =
+ i2c0 = _0;
+ i2c1 = _1;
+ i2c2 = _2;
};
config {
@@ -213,6 +216,28 @@
};
};
+ i2c_0: i2c2@16,0 {
+ compatible = "snps,designware-i2c-pci";
+ reg = <0x0200b010 0 0 0 0>;
+ };
+
+ i2c_1: i2c2@16,1 {
+ compatible = "snps,designware-i2c-pci";
+ reg = <0x0200b110 0 0 0 0>;
+ };
+
+ i2c_2: i2c2@16,2 {
+ compatible = "snps,designware-i2c-pci";
+ reg = <0x0200b210 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ tpm@50 {
+ reg = <0x50>;
+ compatible = "google,cr50";
+ u-boot,i2c-offset-len = <0>;
+ };
+ };
+
serial: serial@18,2 {
reg = <0x0200c210 0 0 0 0>;
u-boot,dm-pre-reloc;
--
2.24.0.rc1.363.gb1bccd3e3d-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/7] pci: i2c: designware: Add compatible string
Add a compatible string for this driver so that it can have children.
Signed-off-by: Simon Glass
---
drivers/i2c/dw_i2c_pci.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/i2c/dw_i2c_pci.c b/drivers/i2c/dw_i2c_pci.c
index 34cdc7bf59..193ad5225f 100644
--- a/drivers/i2c/dw_i2c_pci.c
+++ b/drivers/i2c/dw_i2c_pci.c
@@ -64,9 +64,15 @@ static int designware_i2c_pci_bind(struct udevice *dev)
return 0;
}
+static const struct udevice_id designware_i2c_pci_ids[] = {
+ { .compatible = "snps,designware-i2c-pci" },
+ { }
+};
+
U_BOOT_DRIVER(i2c_designware_pci) = {
.name = "i2c_designware_pci",
.id = UCLASS_I2C,
+ .of_match = designware_i2c_pci_ids,
.bind = designware_i2c_pci_bind,
.probe = designware_i2c_pci_probe,
.priv_auto_alloc_size = sizeof(struct dw_i2c),
--
2.24.0.rc1.363.gb1bccd3e3d-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/7] i2c: designware: Drop invalid debugging
This printf() should not be there.
Signed-off-by: Simon Glass
---
drivers/i2c/designware_i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 54e4a70c74..b12ad02a43 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -540,7 +540,6 @@ static int designware_i2c_ofdata_to_platdata(struct udevice
*bus)
{
struct dw_i2c *priv = dev_get_priv(bus);
- printf("bad\n");
priv->regs = (struct i2c_regs *)devfdt_get_addr_ptr(bus);
return 0;
--
2.24.0.rc1.363.gb1bccd3e3d-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cbfs: do not pack struct cbfs_cachenode
On Mon, Oct 7, 2019 at 6:37 AM Heinrich Schuchardt wrote: > > With the __packed attribute sandbox_defconfig cannot be compiled with GCC > 9.2.1: > > fs/cbfs/cbfs.c: In function ‘file_cbfs_fill_cache’: > fs/cbfs/cbfs.c:164:16: error: taking address of packed member of > ‘struct cbfs_cachenode’ may result in an unaligned pointer value > [-Werror=address-of-packed-member] > 164 | cache_tail = _node->next; > |^~~ > > struct cbfs_cachenode is only an internal structure. So let's rearrange the > fields such that the structure is naturally packed and remove the __packed > attribute. > > Signed-off-by: Heinrich Schuchardt > --- > include/cbfs.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Different build result for board "tbs2910" in gitlab-ci and azure
Hi Bin, On Sat, Nov 2, 2019 at 3:03 PM Bin Meng wrote: > > Hi Tom, > > When I build Simon's patches (the one I applied to u-boot-x86 today), > I noticed that the build results for board "tbs2910" in gitlab-ci and > azure are different. > > On gitlab-ci [1], the build fails with error message: > >arm: + tbs2910 > +u-boot.imx exceeds file size limit: > + limit: 0x5fc00 bytes > + actual: 0x60c00 bytes > + excess: 0x1000 bytes > +make[1]: *** [u-boot.imx] Error 1 > +make[1]: *** Deleting file 'u-boot.imx' > +make: *** [sub-make] Error 2 > > 125 3311 /7010:17:40 : tbs2910 > > On azure [2] job "Build the World imx6", the build succeeds: > >arm: w+ tbs2910 > += WARNING == > +This board does not use CONFIG_DM_VIDEO Please update > +the board to use CONFIG_DM_VIDEO before the v2019.07 release. > +Failure to update by the deadline may result in board removal. > +See doc/driver-model/MIGRATION.txt for more info. > + > +CONFIG_OF_EMBED is enabled. This option should only > +be used for debugging purposes. Please use > +CONFIG_OF_SEPARATE for boards in mainline. > +See doc/README.fdt-control for more info. > > 6 240 /55 0:07:44 : tbs2910 > > I am not sure what might be the problem. Do you know what could be the cause? > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/26524 > [2] https://dev.azure.com/bmeng/GitHub/_build/results?buildId=135 > > Regards, > Bin > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot That is toolchain version specific issue(there was a discussion about this board [1]). On Azure gcc-9.1.0-2 is used In gitlab-ci - gcc-7.3.0. [1] https://patchwork.ozlabs.org/patch/1180025/ -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 001/108] binman: Correct symbol calculation with non-zero image base
On Mon, Oct 28, 2019 at 11:27 AM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > At present binman adds the image base address to the symbol value before > > it writes it to the binary. This is not correct since the symbol value > > itself (e.g. image position) has no relationship to the image base. > > > > Fix this and update the tests to cover this case. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > tools/binman/elf.py | 4 +--- > > tools/binman/test/u_boot_binman_syms.lds | 2 +- > > 2 files changed, 2 insertions(+), 4 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 002/108] binman: Add support for Intel FSP-S
On Mon, Oct 28, 2019 at 11:27 AM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > This entry is used to hold an Intel FSP-S (Firmware Support Package > > Silicon init) binary. Add support for this in binman. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > tools/binman/README.entries | 17 + > > tools/binman/etype/intel_fsp_s.py | 27 +++ > > tools/binman/ftest.py | 6 ++ > > tools/binman/test/153_intel_fsp_s.dts | 14 ++ > > 4 files changed, 64 insertions(+) > > create mode 100644 tools/binman/etype/intel_fsp_s.py > > create mode 100644 tools/binman/test/153_intel_fsp_s.dts > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 003/108] binman: Add support for Intel FSP-T
On Mon, Oct 28, 2019 at 11:27 AM Bin Meng wrote: > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > This entry is used to hold an Intel FSP-T (Firmware Support Package > > Temp-RAM init) binary. Add support for this in binman. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > tools/binman/README.entries | 16 > > tools/binman/etype/intel_fsp_t.py | 26 ++ > > tools/binman/ftest.py | 7 +++ > > tools/binman/test/154_intel_fsp_t.dts | 14 ++ > > 4 files changed, 63 insertions(+) > > create mode 100644 tools/binman/etype/intel_fsp_t.py > > create mode 100644 tools/binman/test/154_intel_fsp_t.dts > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] spi: nxp_fspi: new driver for the FlexSPI controller
This is a port of the kernel's spi-nxp-fspi driver. It uses the new spi-mem interface and does not expose the more generic spi-xfer interface. The source was taken from the v5.3-rc3 tag. The port was straightforward: - remove the interrupt handling and the completion by busy polling the controller - remove locks - move the setup of the memory windows into claim_bus() - move the setup of the speed into set_speed() - port the device tree bindings from the original fspi_probe() to ofdata_to_platdata() There were only some style change fixes, no change in any logic. For example, there are busy loops where the return code is not handled correctly, eg. only prints a warning with WARN_ON(). This port intentionally left most functions unchanged to ease future bugfixes. This was tested on a custom LS1028A board. Because the LS1028A doesn't have proper clock framework support, changing the clock speed was not tested. This also means that it is not possible to change the SPI speed on LS1028A for now (neither is it possible in the linux driver). Signed-off-by: Michael Walle Reviewed-by: Jagan Teki --- changes since v1: - fixed typo, thanks Jagan drivers/spi/Kconfig| 7 + drivers/spi/Makefile | 1 + drivers/spi/nxp_fspi.c | 997 + 3 files changed, 1005 insertions(+) create mode 100644 drivers/spi/nxp_fspi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 7be867d5b6..ad20309df8 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -192,6 +192,13 @@ config MVEBU_A3700_SPI used to access the SPI NOR flash on platforms embedding this Marvell IP core. +config NXP_FSPI + bool "NXP FlexSPI driver" + depends on SPI_MEM + help + Enable the NXP FlexSPI (FSPI) driver. This driver can be used to + access the SPI NOR flash on platforms embedding this NXP IP core. + config PIC32_SPI bool "Microchip PIC32 SPI driver" depends on MACH_PIC32 diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index ae4f2958f8..52462e19a3 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -43,6 +43,7 @@ obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o obj-$(CONFIG_MXC_SPI) += mxc_spi.o obj-$(CONFIG_MXS_SPI) += mxs_spi.o +obj-$(CONFIG_NXP_FSPI) += nxp_fspi.o obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o obj-$(CONFIG_PIC32_SPI) += pic32_spi.o diff --git a/drivers/spi/nxp_fspi.c b/drivers/spi/nxp_fspi.c new file mode 100644 index 00..b808418eb6 --- /dev/null +++ b/drivers/spi/nxp_fspi.c @@ -0,0 +1,997 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * NXP FlexSPI(FSPI) controller driver. + * + * Copyright (c) 2019 Michael Walle + * + * This driver was originally ported from the linux kernel v5.4-rc3, which had + * the following notes: + * + * Copyright 2019 NXP. + * + * FlexSPI is a flexsible SPI host controller which supports two SPI + * channels and up to 4 external devices. Each channel supports + * Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional + * data lines). + * + * FlexSPI controller is driven by the LUT(Look-up Table) registers + * LUT registers are a look-up-table for sequences of instructions. + * A valid sequence consists of four LUT registers. + * Maximum 32 LUT sequences can be programmed simultaneously. + * + * LUTs are being created at run-time based on the commands passed + * from the spi-mem framework, thus using single LUT index. + * + * Software triggered Flash read/write access by IP Bus. + * + * Memory mapped read access by AHB Bus. + * + * Based on SPI MEM interface and spi-fsl-qspi.c driver. + * + * Author: + * Yogesh Narayan Gaur + * Boris Brezillon + * Frieder Schrempf + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * The driver only uses one single LUT entry, that is updated on + * each call of exec_op(). Index 0 is preset at boot with a basic + * read operation, so let's use the last entry (31). + */ +#defineSEQID_LUT 31 + +/* Registers used by the driver */ +#define FSPI_MCR0 0x00 +#define FSPI_MCR0_AHB_TIMEOUT(x) ((x) << 24) +#define FSPI_MCR0_IP_TIMEOUT(x)((x) << 16) +#define FSPI_MCR0_LEARN_EN BIT(15) +#define FSPI_MCR0_SCRFRUN_EN BIT(14) +#define FSPI_MCR0_OCTCOMB_EN BIT(13) +#define FSPI_MCR0_DOZE_EN BIT(12) +#define FSPI_MCR0_HSEN BIT(11) +#define FSPI_MCR0_SERCLKDIVBIT(8) +#define FSPI_MCR0_ATDF_EN BIT(7) +#define FSPI_MCR0_ARDF_EN BIT(6) +#define FSPI_MCR0_RXCLKSRC(x) ((x) << 4) +#define FSPI_MCR0_END_CFG(x) ((x) << 2) +#define FSPI_MCR0_MDIS BIT(1) +#define FSPI_MCR0_SWRSTBIT(0) + +#define
[U-Boot] [PATCH v2 2/2] arm: ls1028a: use the new flexspi driver
Also align the fspi node with the kernel one. There is actually no driver
which would match "nxp,dn-fspi".
Signed-off-by: Michael Walle
---
changes since v1:
- none
arch/arm/dts/fsl-ls1028a.dtsi | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 43a154e8e7..774e477542 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -49,14 +49,16 @@
<1 10 0x8>; /* Hypervisor PPI, active-low */
};
- fspi: flexspi@20C {
- compatible = "nxp,dn-fspi";
+ fspi: flexspi@20c {
+ compatible = "nxp,lx2160a-fspi";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x0 0x20C 0x0 0x1>,
- <0x0 0x2000 0x0 0x1000>; /*64MB flash*/
- reg-names = "FSPI", "FSPI-memory";
- num-cs = <1>;
+ reg = <0x0 0x20c 0x0 0x1>,
+ <0x0 0x2000 0x0 0x1000>;
+ reg-names = "fspi_base", "fspi_mmap";
+ clocks = < 4 3>, < 4 3>;
+ clock-names = "fspi_en", "fspi";
+ interrupts = <0 25 0x4>;
status = "disabled";
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 026/108] x86: timer: Reduce timer code size in TPL on Intel CPUs
Hi BIn, On Mon, 28 Oct 2019 at 01:27, Bin Meng wrote: > > Hi Simon, > > On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > > > Most of the timer-calibration methods are not needed on recent Intel CPUs > > and just increase code size. Add an option to use the known-good way to > > get the clock frequency in TPL. Size reduction is about 700 bytes. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > drivers/timer/Kconfig | 9 + > > drivers/timer/tsc_timer.c | 7 +-- > > 2 files changed, 14 insertions(+), 2 deletions(-) > > > > You mentioned in the v2 that this breaks bootstage, and will drop this > patch. no? > https://www.mail-archive.com/u-boot@lists.denx.de/msg344229.html Ah yes I found the bug with that, and you've applied the patches. Will update the commit message. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 013/108] x86: spi: Add helper functions for Intel Fast SPI
Hi Bin,
On Fri, 1 Nov 2019 at 22:14, Bin Meng wrote:
>
> On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote:
> >
> > Most x86 CPUs use a mechanism where the SPI flash is mapped into the very
> > top of 32-bit address space, so that it can be executed in place and read
> > simply by copying from memory. For an 8MB ROM the mapping starts at
> > 0xff80.
> >
> > However some recent Intel CPUs do not use a simple 1:1 memory map. Instead
> > the map starts at a different address and not all of the SPI flash is
> > accessible through the map. This 'Fast SPI' feature requires that U-Boot
> > check the location of the map. It is also possible (optionally) to read
> > from the SPI flash using a driver.
> >
> > Add support for booting from Fast SPI. The memory-mapped version is used
> > by both TPL and SPL on apollolake.
> >
> > In respect of a SPI flash driver, the actual SPI driver is ich.c - this
> > just adds a few helper functions and definitions.
> >
> > This is used by Apollolake.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v3:
> > - Add support for of-platdata for TPL
> > - Add the missing header file
> > - Change Fast-SPI driver into a helper file used by ICH SPI
> > - Don't include write() and erase() in TPL
> > - Merge in patch "x86: Add support for booting from Fast SPI"
> > - Reorder file so that write() and erase() are together
> > - Use pci_get_devfn()
> >
> > Changes in v2: None
> >
> > arch/x86/cpu/intel_common/Makefile | 1 +
> > arch/x86/cpu/intel_common/fast_spi.c | 73
> > arch/x86/include/asm/fast_spi.h | 68 ++
> > arch/x86/include/asm/spl.h | 1 +
> > 4 files changed, 143 insertions(+)
> > create mode 100644 arch/x86/cpu/intel_common/fast_spi.c
> > create mode 100644 arch/x86/include/asm/fast_spi.h
[..]
> > +/* Register offsets from the MMIO region base (PCI_BASE_ADDRESS_0) */
> > +struct fast_spi_regs {
> > + u32 bfp;
> > + u32 hsfsts_ctl;
> > + u32 faddr;
> > + u32 dlock;
> > +
> > + u32 fdata[0x10];
> > +
> > + u32 fracc;
> > + u32 freg[12];
> > + u32 fpr[5];
> > + u32 gpr0;
> > + u32 spare2;
> > + u32 sts_ctl;
> > + u16 preop; /* a4 */
>
> I assume a4 is the offset of preop? Leaving it causes confusion and it
> can be dropped, I think.
>
Will do.
I'm rebasing on your applied patches and moving the code around to
address Andy's comments. I'll send a new version v4 by Monday.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] tpm: Add a driver for H1/Cr50
On Sat, Nov 2, 2019 at 4:01 PM Simon Glass wrote:
>
> H1 is a Google security chip present in recent Chromebooks, Pixel phones
> and other devices. Cr50 is the name of the software that runs on H1 in
> Chromebooks.
>
> This chip is used to handle TPM-like functionality and also has quite a
> few additional features.
>
> Add a driver for this.
> +/* Wait for interrupt to indicate TPM is ready */
> +static int cr50_i2c_wait_tpm_ready(struct udevice *dev)
> +{
> + struct cr50_priv *priv = dev_get_priv(dev);
> + ulong timeout;
> + int i;
> +
> + if (!dm_gpio_is_valid(>ready_gpio)) {
> + /* Fixed delay if interrupt not supported */
> + udelay(TIMEOUT_NO_IRQ_US);
> + return 0;
> + }
> +
> + timeout = timer_get_us() + TIMEOUT_IRQ_US;
> +
> + i = 0;
> + while (!dm_gpio_get_value(>ready_gpio)) {
> + i++;
> + if (timer_get_us() > timeout) {
> + printf("Timeout\n");
> + /*
> +* Use this instead of -ETIMEDOUT which is used by i2c
> +*/
> + return -ETIME;
> + }
> + }
> +
> + return 0;
> +}
> +
Timeout loops look more naturally if they are done as do {} while.
See:
i = 0;
do {
if (dm_gpio_get_value(>ready_gpio))
return 0;
i++; /* What is this for? */
} while (timeout >= timer_get_us());
printf("Timeout\n");
/*
* Use this instead of -ETIMEDOUT which is used by i2c
*/
return -ETIME;
}
> +static int cr50_i2c_write(struct udevice *dev, u8 addr, const u8 *buffer,
> + size_t len)
> +{
> + u8 buf[len + 1];
VLA?!
> + int ret;
> +
> + if (len > CR50_MAX_BUF_SIZE) {
> + log_err("Length %zd is too large\n", len);
> + return -E2BIG;
> + }
> +}
> +static int request_locality(struct udevice *dev, int loc)
> +{
> + struct cr50_priv *priv = dev_get_priv(dev);
> + u8 buf = TPM_ACCESS_REQUEST_USE;
> + ulong timeout;
> + int ret;
> +
> + ret = check_locality(dev, loc);
> + if (ret < 0)
> + return ret;
> + else if (ret == loc)
Here 'else' is redundant.
> + return loc;
> + timeout = timer_get_us() + TIMEOUT_LONG_US;
> + while (timer_get_us() < timeout) {
Same comment for timeout loops (btw, there is a chance in a while {}
loop that it won't do even first iteretation).
> + ret = check_locality(dev, loc);
> + if (ret < 0)
> + return ret;
> + if (ret == loc) {
> + priv->locality = loc;
> + log_debug("Set locality to %x\n", loc);
> + return loc;
> + }
> + udelay(TIMEOUT_SHORT_US);
> + }
> + printf("Request locality failed\n");
> +
> + return -ETIMEDOUT;
> +}
> + timeout = timer_get_us() + TIMEOUT_LONG_US;
> + while (timer_get_us() < timeout) {
Ditto for all timeout loop related comments.
> + if (cr50_i2c_read(dev, tpm_sts(priv->locality),
> + (u8 *), sizeof(buf)) < 0) {
> + udelay(TIMEOUT_SHORT_US);
> + continue;
> + }
> + timeout = timer_get_us() + TIMEOUT_LONG_US;
> + do {
> + ret = cr50_i2c_status(dev);
> + if (ret)
> + goto out_err;
> + if (!(ret & TPM_STS_COMMAND_READY))
> + break;
> +
> + if (timer_get_us() > timeout)
> + goto out_err;
> +
> + ret = cr50_i2c_ready(dev);
> + if (ret)
> + goto out_err;
> + } while (1);
Better to have non-infinite loops (i.o.w. loops with understandable
exit conditional).
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 016/108] fdt: Show the preprocessed .dts file on error
Hi Bin, On Mon, 28 Oct 2019 at 00:47, Bin Meng wrote: > > Hi Simon, > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > When device-tree compilation fails it is sometimes tricky to see which > > line is broken, since the input file to dtc is a pre-processed version > > of the device tree. > > > > Add a line that points to the file that needs to be checked: > > > > Output is something like this: > > > > Error: arch/x86/dts/u-boot.dtsi:137.14-15 syntax error > > To me this already provides enough information for people to look at. > I don't think we need another line to duplicate the report. > > > FATAL ERROR: Unable to parse input tree > > Check /tmp/b/chromebook_coral/arch/x86/dts/.chromebook_coral.dtb.pre.tmp > > Another reason is that if the error does not happen in the dtsi file > but the main dts file, the line you added here is a duplicates of the > error message coming from the dtc. > Part of the problem here is that the commit shows the un-preprocessed filename. I'll fix that and add a longer description. This commit has saved my bacon quite a few times and I think it has value. Hopefully you agree once you try it out, but if not, I'm going to drop it. > >for errors > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Update example error message to better show the intended purpose > > > > Changes in v2: None > > > > scripts/Makefile.lib | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Different build result for board "tbs2910" in gitlab-ci and azure
Hi Igor, On Sat, Nov 2, 2019 at 11:26 PM Igor Opaniuk wrote: > > Hi Bin, > > On Sat, Nov 2, 2019 at 3:03 PM Bin Meng wrote: > > > > Hi Tom, > > > > When I build Simon's patches (the one I applied to u-boot-x86 today), > > I noticed that the build results for board "tbs2910" in gitlab-ci and > > azure are different. > > > > On gitlab-ci [1], the build fails with error message: > > > >arm: + tbs2910 > > +u-boot.imx exceeds file size limit: > > + limit: 0x5fc00 bytes > > + actual: 0x60c00 bytes > > + excess: 0x1000 bytes > > +make[1]: *** [u-boot.imx] Error 1 > > +make[1]: *** Deleting file 'u-boot.imx' > > +make: *** [sub-make] Error 2 > > > > 125 3311 /7010:17:40 : tbs2910 > > > > On azure [2] job "Build the World imx6", the build succeeds: > > > >arm: w+ tbs2910 > > += WARNING == > > +This board does not use CONFIG_DM_VIDEO Please update > > +the board to use CONFIG_DM_VIDEO before the v2019.07 release. > > +Failure to update by the deadline may result in board removal. > > +See doc/driver-model/MIGRATION.txt for more info. > > + > > +CONFIG_OF_EMBED is enabled. This option should only > > +be used for debugging purposes. Please use > > +CONFIG_OF_SEPARATE for boards in mainline. > > +See doc/README.fdt-control for more info. > > > > 6 240 /55 0:07:44 : tbs2910 > > > > I am not sure what might be the problem. Do you know what could be the > > cause? > > > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/26524 > > [2] https://dev.azure.com/bmeng/GitHub/_build/results?buildId=135 > > > > Regards, > > Bin > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > That is toolchain version specific issue(there was a discussion about > this board [1]). > Thanks for checking. > On Azure gcc-9.1.0-2 is used > In gitlab-ci - gcc-7.3.0. > But I don't understand why this is caused by GCC version. Azure is using the same CI runner docker image used by gitlab-ci so compiler version should be the same. > [1] https://patchwork.ozlabs.org/patch/1180025/ > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-x86
Hi Tom, This PR includes the following changes for x86: - Add support for Intel FSP-S and FSP-T in binman - Correct priority selection for image loaders for SPL - Add a size check for TPL - Various small SPL/TPL bug fixes and changes - SPI: Add support for memory-mapped flash The following changes since commit 5d6f05352b69d4858a2a9e9136ac3a734f0222bb: azure: Update the script to prepend PATH not override PATH (2019-11-01 13:59:14 -0400) are available in the git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-x86 for you to fetch changes up to 73c6cd6c0bdb3af76d573f619bbcc141758bb16b: x86: Quieten TPL's jump_to_image_no_args() (2019-11-03 07:20:29 +0800) Heinrich Schuchardt (1): cbfs: do not pack struct cbfs_cachenode Simon Glass (16): binman: Correct symbol calculation with non-zero image base binman: Add support for Intel FSP-S binman: Add support for Intel FSP-T binman: Fix up comment in intel-fsp-m spl: Correct priority selection for image loaders spi: Add support for memory-mapped flash dm: doc: Correct of-platdata driver name spl: Add a size check for TPL x86: timer: Set up the timer in timer_early_get_count() x86: timer: Use a separate flag for whether timer is inited x86: spl: Support init of a PUNIT x86: tpl: Add a fake PCI bus x86: Add a CPU init function for TPL x86: Move CPU init to before spl_init() x86: Don't print CPU info in TPL x86: Quieten TPL's jump_to_image_no_args() Makefile | 7 +++ arch/x86/cpu/i386/cpu.c | 8 arch/x86/cpu/start_from_spl.S| 1 + arch/x86/include/asm/cpu.h | 1 + arch/x86/include/asm/global_data.h | 1 + arch/x86/include/asm/u-boot-x86.h| 9 + arch/x86/lib/spl.c | 44 arch/x86/lib/tpl.c | 37 +++-- common/spl/Kconfig | 8 doc/driver-model/of-plat.rst | 2 +- drivers/spi/sandbox_spi.c| 11 +++ drivers/spi/spi-uclass.c | 14 ++ drivers/timer/tsc_timer.c| 5 - include/cbfs.h | 6 +++--- include/spi.h| 27 +++ include/spl.h| 4 ++-- test/dm/sf.c | 9 + tools/binman/README.entries | 33 + tools/binman/elf.py | 4 +--- tools/binman/etype/intel_fsp_m.py| 2 +- tools/binman/etype/intel_fsp_s.py| 27 +++ tools/binman/etype/intel_fsp_t.py| 26 ++ tools/binman/ftest.py| 13 + tools/binman/test/153_intel_fsp_s.dts| 14 ++ tools/binman/test/154_intel_fsp_t.dts| 14 ++ tools/binman/test/u_boot_binman_syms.lds | 2 +- 26 files changed, 311 insertions(+), 18 deletions(-) create mode 100644 tools/binman/etype/intel_fsp_s.py create mode 100644 tools/binman/etype/intel_fsp_t.py create mode 100644 tools/binman/test/153_intel_fsp_s.dts create mode 100644 tools/binman/test/154_intel_fsp_t.dts Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] buildman: Fix problem with non-existent output directories
On Sat, Nov 02, 2019 at 11:54:44AM +0800, Bin Meng wrote:
> On Sat, Nov 2, 2019 at 5:48 AM Tom Rini wrote:
> >
> > Now that we have buildman telling genboards.cfg to use an output
> > directory we need to ensure that it exists.
> >
> > Cc: Bin Meng
> > Cc: Simon Glass
> > Fixes: bc750bca1246 ("tools: buildman: Honor output directory when
> > generating boards.cfg")
> > Signed-off-by: Tom Rini
> > ---
> > tools/buildman/control.py | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/tools/buildman/control.py b/tools/buildman/control.py
> > index 9787b8674761..5988ada72b75 100644
> > --- a/tools/buildman/control.py
> > +++ b/tools/buildman/control.py
> > @@ -201,6 +201,8 @@ def DoBuildman(options, args, toolchains=None,
> > make_func=None, boards=None,
> >
> > # Work out what subset of the boards we are building
> > if not boards:
> > +if not os.path.exists(options.output_dir):
> > +os.mkdir(options.output_dir)
>
> Use os.makedirs() ?
Ah, in case we need more than one directory made? OK, I'll do v2
shortly.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 018/108] Revert "RFC: sandbox: net: Suppress the MAC-address warnings"
Hi Bin, On Mon, 28 Oct 2019 at 00:16, Bin Meng wrote: > > Hi Simon, > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > This reverts commit 96ac4def8b6686de8566b91419ce98cd5765079b. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: None > > Changes in v2: None > > > > arch/sandbox/cpu/state.c | 12 ++-- > > arch/sandbox/include/asm/state.h | 5 + > > cmd/nvedit.c | 8 > > include/configs/sandbox.h| 7 +-- > > include/env.h| 12 > > net/eth-uclass.c | 11 ++- > > test/dm/test-main.c | 2 +- > > 7 files changed, 11 insertions(+), 46 deletions(-) > > > > I don't understand the revert. Is this because the previous patch will > break the following patches in this series? Yes...despite my efforts the env variables seem to be protected from being changed...so tests fail. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/1] efi_loader: disk: install file system protocol to a whole disk
From: AKASHI Takahiro
Currently, a whole disk without any partitions is not associated
with EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. So even if it houses some
file system, there is a chance that we may not be able to access
it, particularly, when accesses are to be attempted after searching
that protocol against a device handle.
With this patch, EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is installed
to such a disk if part_get_info() shows there is no partition
table installed on it.
Signed-off-by: AKASHI Takahiro
Only if no partition table exists, check for a file system on disk level.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_disk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 861fcaf374..ed7fb3f7d3 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -337,7 +337,9 @@ static efi_status_t efi_disk_add_dev(
diskobj->dp);
if (ret != EFI_SUCCESS)
return ret;
- if (part >= 1 && efi_fs_exists(desc, part)) {
+ /* partitions or whole disk without partitions */
+ if ((part || desc->part_type == PART_TYPE_UNKNOWN) &&
+ efi_fs_exists(desc, part)) {
diskobj->volume = efi_simple_file_system(desc, part,
diskobj->dp);
ret = efi_add_protocol(>header,
--
2.24.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 006/108] dm: gpio: Allow control of GPIO uclass in SPL
Hi Simon, On Sat, Nov 2, 2019 at 5:38 PM Bin Meng wrote: > > On Mon, Oct 28, 2019 at 12:45 PM Bin Meng wrote: > > > > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote: > > > > > > At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass > > > is included in SPL/TPL without any control for boards. Some boards may > > > want to disable this to reduce code size where GPIOs are not needed in > > > SPL or TPL. > > > > > > Add a new Kconfig option to permit this. Default it to 'y' so that > > > existing boards work correctly. > > > > > > Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to > > > preserve the current behaviour. Also update the 74x164 GPIO driver since > > > it cannot build with SPL. > > > > > > This allows us to remove the hacks in config_uncmd_spl.h and > > > Makefile.uncmd_spl (eventually those files should be removed). > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > Changes in v3: None > > > Changes in v2: > > > - Fix the Kconfig condition to avoid build errors on snow > > > > > > arch/arm/include/asm/omap_gpio.h | 2 +- > > > arch/arm/mach-at91/include/mach/at91sam9260.h | 2 +- > > > arch/arm/mach-davinci/include/mach/gpio.h | 2 +- > > > arch/arm/mach-omap2/am33xx/board.c| 4 ++-- > > > arch/arm/mach-omap2/omap3/board.c | 2 +- > > > arch/arm/mach-omap2/omap5/hwinit.c| 2 +- > > > board/freescale/imx8qm_mek/imx8qm_mek.c | 2 +- > > > board/freescale/imx8qxp_mek/imx8qxp_mek.c | 2 +- > > > board/gateworks/gw_ventana/Kconfig| 3 +++ > > > board/toradex/apalis-imx8/apalis-imx8.c | 2 +- > > > drivers/gpio/Kconfig | 22 +++ > > > drivers/gpio/Makefile | 4 +++- > > > drivers/gpio/at91_gpio.c | 6 ++--- > > > drivers/gpio/atmel_pio4.c | 2 +- > > > drivers/gpio/da8xx_gpio.c | 6 ++--- > > > drivers/gpio/da8xx_gpio.h | 2 +- > > > drivers/gpio/mxc_gpio.c | 4 ++-- > > > drivers/gpio/mxs_gpio.c | 4 ++-- > > > drivers/gpio/omap_gpio.c | 6 ++--- > > > drivers/gpio/sunxi_gpio.c | 8 +++ > > > drivers/i2c/i2c-uclass.c | 6 ++--- > > > drivers/i2c/muxes/pca954x.c | 4 ++-- > > > drivers/mmc/fsl_esdhc_imx.c | 13 ++- > > > drivers/mmc/omap_hsmmc.c | 2 +- > > > drivers/net/designware.c | 10 - > > > drivers/net/designware.h | 4 ++-- > > > drivers/net/fec_mxc.c | 6 ++--- > > > drivers/net/fec_mxc.h | 2 +- > > > drivers/net/mvneta.c | 4 ++-- > > > drivers/net/mvpp2.c | 8 +++ > > > drivers/net/sun8i_emac.c | 12 +- > > > drivers/pci/pci-aardvark.c| 4 ++-- > > > drivers/pci/pcie_dw_mvebu.c | 4 ++-- > > > drivers/spi/atmel_spi.c | 10 - > > > drivers/spi/designware_spi.c | 4 ++-- > > > drivers/tpm/tpm2_tis_spi.c| 2 +- > > > include/config_uncmd_spl.h| 1 - > > > include/configs/at91-sama5_common.h | 5 +++-- > > > include/configs/gw_ventana.h | 1 - > > > include/configs/mx6ul_14x14_evk.h | 1 + > > > scripts/Makefile.uncmd_spl| 1 - > > > 41 files changed, 109 insertions(+), 82 deletions(-) > > > > > > > Reviewed-by: Bin Meng > > applied to u-boot-x86, thanks! Unfortunately this patch still breaks one board. See the log below: The failed build: https://dev.azure.com/bmeng/GitHub/_build/results?buildId=135 arm: + omap35_logic +arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 844 bytes +make[2]: *** [spl/u-boot-spl] Error 1 +make[1]: *** [spl/u-boot-spl] Error 2 +make: *** [sub-make] Error 2 0 121 /34 0:09:42 : omap35_logic The passed build with this commit reverted: https://dev.azure.com/bmeng/GitHub/_build/results?buildId=136 I will have to drop this patch from the queue. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 013/108] x86: spi: Add helper functions for Intel Fast SPI
Hi Simon,
On Sun, Nov 3, 2019 at 5:04 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Fri, 1 Nov 2019 at 22:14, Bin Meng wrote:
> >
> > On Mon, Oct 21, 2019 at 11:33 AM Simon Glass wrote:
> > >
> > > Most x86 CPUs use a mechanism where the SPI flash is mapped into the very
> > > top of 32-bit address space, so that it can be executed in place and read
> > > simply by copying from memory. For an 8MB ROM the mapping starts at
> > > 0xff80.
> > >
> > > However some recent Intel CPUs do not use a simple 1:1 memory map. Instead
> > > the map starts at a different address and not all of the SPI flash is
> > > accessible through the map. This 'Fast SPI' feature requires that U-Boot
> > > check the location of the map. It is also possible (optionally) to read
> > > from the SPI flash using a driver.
> > >
> > > Add support for booting from Fast SPI. The memory-mapped version is used
> > > by both TPL and SPL on apollolake.
> > >
> > > In respect of a SPI flash driver, the actual SPI driver is ich.c - this
> > > just adds a few helper functions and definitions.
> > >
> > > This is used by Apollolake.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > Changes in v3:
> > > - Add support for of-platdata for TPL
> > > - Add the missing header file
> > > - Change Fast-SPI driver into a helper file used by ICH SPI
> > > - Don't include write() and erase() in TPL
> > > - Merge in patch "x86: Add support for booting from Fast SPI"
> > > - Reorder file so that write() and erase() are together
> > > - Use pci_get_devfn()
> > >
> > > Changes in v2: None
> > >
> > > arch/x86/cpu/intel_common/Makefile | 1 +
> > > arch/x86/cpu/intel_common/fast_spi.c | 73
> > > arch/x86/include/asm/fast_spi.h | 68 ++
> > > arch/x86/include/asm/spl.h | 1 +
> > > 4 files changed, 143 insertions(+)
> > > create mode 100644 arch/x86/cpu/intel_common/fast_spi.c
> > > create mode 100644 arch/x86/include/asm/fast_spi.h
> [..]
>
> > > +/* Register offsets from the MMIO region base (PCI_BASE_ADDRESS_0) */
> > > +struct fast_spi_regs {
> > > + u32 bfp;
> > > + u32 hsfsts_ctl;
> > > + u32 faddr;
> > > + u32 dlock;
> > > +
> > > + u32 fdata[0x10];
> > > +
> > > + u32 fracc;
> > > + u32 freg[12];
> > > + u32 fpr[5];
> > > + u32 gpr0;
> > > + u32 spare2;
> > > + u32 sts_ctl;
> > > + u16 preop; /* a4 */
> >
> > I assume a4 is the offset of preop? Leaving it causes confusion and it
> > can be dropped, I think.
> >
>
> Will do.
>
> I'm rebasing on your applied patches and moving the code around to
> address Andy's comments. I'll send a new version v4 by Monday.
Or maybe you can wait until I looked at all v3 patches. I just wanted
to send a PR for a collection of good patches so far, instead of
giving Tom a huge list :)
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
