December 2018 - U-Boot

[U-Boot] [PATCH 0/7] Remove defines for SPI default speed and mode
by Patrick Delaunay 13 Dec '18

13 Dec '18

This patch-set finish (after the last Simmon comment) and depends on the previous serie named: "Read default speed and mode values from DT" http://patchwork.ozlabs.org/project/uboot/list/?series=76834 This patchset remove the unnecessary defines for SPI speed and mode when DM mode is used for SPI (CONFIG_DM_SPI_FLASH). Build result is available for the serie in gihub and travis: https://github.com/patrickdelaunay/u-boot/tree/topic/spi https://travis-ci.org/patrickdelaunay/u-boot/branches Patrick Delaunay (7): spi: update management of default speed and mode spi: add comment for spi_flash_probe_bus_cs function da850evm: sf: Read default speed and mode values from DT dfu: sf: Read default speed and mode values from DT mips: mt76xx: gardena-smart-gateway: Read default speed and mode values from DT env: Read default speed and mode values from DT spi: remove define for SPI default SPEED and MODE board/davinci/da8xxevm/da850evm.c | 7 +++++++ board/gardena/smart-gateway-mt7688/board.c | 24 ++++++++++++++++++++---- cmd/sf.c | 10 ++++++---- common/spl/spl_spi.c | 11 ++++++----- common/splash_source.c | 11 ++++++----- drivers/dfu/dfu_sf.c | 10 ++++++++-- env/Kconfig | 4 ++-- env/sf.c | 5 ++++- include/spi_flash.h | 18 ++++++++++++++++++ 9 files changed, 77 insertions(+), 23 deletions(-) -- 2.7.4

8 33

[U-Boot] [PATCH v2] zynq-gem: Flush cache before handing RX packet to receive handler
by Stefan Theil 13 Dec '18

13 Dec '18

Signed-off-by: Stefan Theil <stefan.theil(a)mixed-mode.de> --- Changes for v2: - Use invalidate_dcache_range instead of flush_dcache_range --- drivers/net/zynq_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index 9bd79b198a..32a0ff392f 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -621,6 +621,9 @@ static int zynq_gem_recv(struct udevice *dev, int flags, uchar **packetp) *packetp = (uchar *)(uintptr_t)addr; + invalidate_dcache_range(addr, addr + roundup(PKTSIZE_ALIGN, ARCH_DMA_MINALIGN)); + barrier(); + return frame_len; } -- 2.17.1

2 1

Re: [U-Boot] [PATCH] zynq-gem: Flush cache before handing RX packet to receive handler
by Stefan Theil 13 Dec '18

13 Dec '18

Hmm good question. I went with flush because that's what's done in the transmit function: addr = (ulong) ptr; addr &= ~(ARCH_DMA_MINALIGN - 1); size = roundup(len, ARCH_DMA_MINALIGN); flush_dcache_range(addr, addr + size); addr = (ulong)priv->rxbuffers; addr &= ~(ARCH_DMA_MINALIGN - 1); size = roundup((RX_BUF * PKTSIZE_ALIGN), ARCH_DMA_MINALIGN); flush_dcache_range(addr, addr + size); barrier(); But since we actually want the uncached data invalidation seems logical. I have to admit though, I don't have much experience with caches. This patch completely fixed my problem... Maybe somebody with a bit more expertise can add their opinion? Regards, Stefan > -----Ursprüngliche Nachricht----- > Von: Bin Meng [mailto:bmeng.cn@gmail.com] > Gesendet: Donnerstag, 13. Dezember 2018 14:13 > An: Stefan Theil > Cc: U-Boot Mailing List > Betreff: Re: [U-Boot] [PATCH] zynq-gem: Flush cache before handing RX > packet to receive handler > > On Thu, Dec 13, 2018 at 6:18 PM Stefan Theil <stefan.theil(a)mixed-mode.de> > wrote: > > > > The cache was only flushed before *transmitting* packets, but not when > > receiving them, leading to an issue where new packets were handed to > > the receive handler with old contents in cache. This only happens when > > a lot of packets are received without sending packages every now and > > then. > > > > Signed-off-by: Stefan Theil <stefan.theil(a)mixed-mode.de> > > --- > > drivers/net/zynq_gem.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index > > 9bd79b198a..5825b6dd99 100644 > > --- a/drivers/net/zynq_gem.c > > +++ b/drivers/net/zynq_gem.c > > @@ -621,6 +621,9 @@ static int zynq_gem_recv(struct udevice *dev, int > > flags, uchar **packetp) > > > > *packetp = (uchar *)(uintptr_t)addr; > > > > + flush_dcache_range(addr, addr + roundup(PKTSIZE_ALIGN, > > + ARCH_DMA_MINALIGN)); > > Shouldn't it be invalidate_dcache_range()? > > > + barrier(); > > + > > return frame_len; > > } > > > > Regards, > Bin

3 6

[U-Boot] [PATCH] usb: composite: Fix max packet size for USB3.0
by Siva Durga Prasad Paladugu 13 Dec '18

13 Dec '18

For USB3.0, the max packetsize for GET_DESCRIPTOR should be sent as exponent value for 2. This means for 512, max packet size should be filled with 9(2^9=512). Also, fill the USB version field with 3.0 if speed is negotiated to Superspeed. This fixes the issue of DFU gadget download failure with superspeed. Without this patch, the max packet size is overflowed to zero as the bMaxPacketsize is of u8 and hence host is not able to detect this device. Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu(a)xilinx.com> Reviewed-by: Bin Meng <bmeng.cn(a)gmail.com> --- Changes from RFC: - Fixed typo in description as per comment. --- drivers/usb/gadget/composite.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index 5106cc5..c7e7623 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -735,8 +735,21 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) case USB_DT_DEVICE: cdev->desc.bNumConfigurations = count_configs(cdev, USB_DT_DEVICE); - cdev->desc.bMaxPacketSize0 = - cdev->gadget->ep0->maxpacket; + + /* + * If the speed is Super speed, then the supported + * max packet size is 512 and it should be sent as + * exponent of 2. So, 9(2^9=512) should be filled in + * bMaxPacketSize0. Also fill USB version as 3.0 + * if speed is Super speed. + */ + if (cdev->gadget->speed == USB_SPEED_SUPER) { + cdev->desc.bMaxPacketSize0 = 9; + cdev->desc.bcdUSB = cpu_to_le16(0x0300); + } else { + cdev->desc.bMaxPacketSize0 = + cdev->gadget->ep0->maxpacket; + } value = min(w_length, (u16) sizeof cdev->desc); memcpy(req->buf, &cdev->desc, value); break; -- 2.7.4

3 2

[U-Boot] [GIT] Pull request: u-boot-dfu (13.12.2018)
by Lukasz Majewski 13 Dec '18

13 Dec '18

Dear Marek, The following changes since commit 51b24944fdbfa760aa87a1ad812355e1df9c9355: usb: musb: Remove legacy CONFIG_USB_DA8XX (2018-12-12 15:23:04 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git for you to fetch changes up to 8a3755462f65c032528af70c6582abf89f91b2bc: configs: am335x_boneblack_vboot: enable DM_USB and RNDIS boot in SPl (2018-12-12 15:35:08 +0100) ---------------------------------------------------------------- Jean-Jacques Hiblot (20): usb: dwc3-generic: make it compatible with "ti, keystone-dwc3" board: ks2_evm: Enable the USB clocks if DM_USB is used ARM: dts: k2g-evm: enable USB0 and USB1 PHY: Add phy driver for the keystone USB PHY usb: host: replace xhci-keystone driver by the generic dwc3 driver configs: k2g_evm: Enable DFU on K2G EVM spl: drivers: Link usb common library to SPL if USB gadget is enabled spl: net: dm: usb: bind the gadget before attempting to load the image phy: omap_usb2: Add support for am437x dwc3-generic: Add support for the am437x board: ti: am43xx: turn on USB clocks dts: Add a u-boot specific dtsi file for the am4372 dts: am4372: Enable USB1 in SPL configs: am43xx_evm: Enable DM_USB and DM_USB_GADGET configs: am43xx: Enable RNDIS support in SPL usb: musb-new: Allow the diver not to use the set_phy_power() callback usb: musb-new: Add support for DM_USB arm: am33xx: Register USB controllers if DM_USB is used but not OF_CONTROL configs: am335x_evm: Do not disable DM_USB in SPL configs: am335x_boneblack_vboot: enable DM_USB and RNDIS boot in SPl arch/arm/dts/am4372-generic-u-boot.dtsi | 2 + arch/arm/dts/am4372-u-boot.dtsi | 40 ++++++++++++++++++ arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 2 + arch/arm/dts/am437x-idk-evm-u-boot.dtsi | 2 + arch/arm/dts/am437x-sk-evm-u-boot.dtsi | 2 + arch/arm/dts/keystone-k2g-evm.dts | 28 +++++++++++++ arch/arm/dts/keystone-k2g.dtsi | 56 +++++++++++++++++++++++++ arch/arm/include/asm/omap_musb.h | 8 ++++ arch/arm/mach-omap2/am33xx/board.c | 58 ++++++++++++++++++++++---- board/ti/am43xx/board.c | 22 ++++++++++ board/ti/ks2_evm/board.c | 12 ++++++ common/Makefile | 3 ++ common/spl/spl_net.c | 4 +- configs/am335x_boneblack_vboot_defconfig | 10 +++++ configs/am43xx_evm_defconfig | 19 +++++++++ configs/k2e_evm_defconfig | 7 ++++ configs/k2e_hs_evm_defconfig | 7 ++++ configs/k2g_evm_defconfig | 12 ++++++ configs/k2g_hs_evm_defconfig | 12 ++++++ configs/k2hk_evm_defconfig | 7 ++++ configs/k2hk_hs_evm_defconfig | 7 ++++ configs/k2l_evm_defconfig | 7 ++++ configs/k2l_hs_evm_defconfig | 7 ++++ drivers/Makefile | 1 + drivers/phy/Kconfig | 10 +++++ drivers/phy/Makefile | 1 + drivers/phy/keystone-usb-phy.c | 109 +++++++++++++++++++++++++++++++++++++++++++++++++ drivers/phy/omap-usb2-phy.c | 45 +++++++++++++++----- drivers/usb/dwc3/dwc3-generic.c | 2 + drivers/usb/host/Makefile | 1 - drivers/usb/host/xhci-keystone.c | 240 ----------------------------------------------------------------------------------------------------------- drivers/usb/musb-new/am35x.c | 8 ++-- drivers/usb/musb-new/musb_dsps.c | 8 ++-- drivers/usb/musb-new/musb_gadget.c | 11 +++++ drivers/usb/musb-new/musb_uboot.c | 4 +- drivers/usb/musb-new/ti-musb.c | 181 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------- include/configs/am335x_evm.h | 1 - include/configs/ti_armv7_keystone2.h | 17 +++++--- 38 files changed, 649 insertions(+), 324 deletions(-) create mode 100644 arch/arm/dts/am4372-u-boot.dtsi create mode 100644 drivers/phy/keystone-usb-phy.c delete mode 100644 drivers/usb/host/xhci-keystone.c Travis-Ci: https://travis-ci.org/lmajewski/u-boot-dfu/builds/467026476 This is the last instalment of patches from Jean-Jacques Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma(a)denx.de

3 5

[U-Boot] [PATCH v3 00/31] virtio: Introduce VirtIO driver support
by Bin Meng 13 Dec '18

13 Dec '18

This series brings in VirtIO driver support in U-Boot. The work is based on Tuomas's virtio support on QEMU ARM targets. VirtIO is a virtualization standard for network and disk device drivers where just the guest's device driver "knows" it is running in a virtual environment, and cooperates with the hypervisor. This enables guests to get high performance network and disk operations, and gives most of the performance benefits of paravirtualization. In the U-Boot case, the guest is U-Boot itself, while the virtual environment are normally QEMU targets like ARM, RISC-V and x86. Both VirtIO MMIO and PCI transport options are supported. Only VirtIO network and block device drivers are supported for now. The following QEMU targets are supported. - qemu_arm_defconfig - qemu_arm64_defconfig - qemu-riscv32_defconfig - qemu-riscv64_defconfig - qemu-x86_defconfig - qemu-x86_64_defconfig A new child_post_probe() uclass driver method is introduced to better support virtio device driver. This also changes BLK uclass driver to supply a post_probe() method which calls part_init(), so that we can avoid duplicating such call in every BLK driver. Not every checkpatch warning reported was fixed, but I tried to fix as many as possible which makes sense. travis-ci build all pass. This series is available at u-boot-x86/virtio-working for testing. Changes in v3: - Exclude VIRTIO_BLK in sandbox_noblk_defconfig build Changes in v2: - new patch to add test case for uclass driver's child_post_probe() - new patch to add dm_remove_devices_flags() call to do_bootm_linux() for riscv bootm - Added virtio spec link and a short statement of what virtio is in the header and source files - Changed to use 'transport' over 'bus' in drivers/virtio/Kconfig - Added UCLASS_VIRTIO ID in alphabetical order - Moved the header file inclusion from virtio.h to C file - Fixed code styling issue (blank line before return) in virtio_xxx() APIs - Changed virtio_init() to return int if there is an error - Added virtio_uclass_pre_probe() to check virtio transport driver ops here so that we don't need check these ops each time when the virtio_xxx APIs are called - Implemented child_post_remove() method to reset the virtio device - Changed virtio_driver_features_init() parameter 'feature' and 'feature_legacy' to const, and adjust member of 'struct virtio_dev_priv' accordingly - Initialize uc_priv->vqs in virtio_uclass_post_probe() - Changed virtio net driver feature table to const - Correct desc->vendor for PCI transport - imply VIRTIO_PCI for qemu-arm too - use an internal function _dm_pci_find_next_capability() for dm_pci_find_capability() and dm_pci_find_next_capability() - adjust swap_case driver to handle request from _dm_pci_find_next_capability() - fix compiler warnings in 64-bit build - adjust virtio_pci_find_capability() to avoid walking through capability list to find next one by ourselves - new patch to add a Sandbox transport driver - new patch to add test cases for virtio uclass - Added driver remove and flags description in the documentation Bin Meng (26): dm: core: Allow uclass to set up a device's child after it is probed test: dm: core: Add test case for uclass driver's child_post_probe() riscv: bootm: Add dm_remove_devices_flags() call to do_bootm_linux() dm: Add a new uclass driver for VirtIO transport devices virtio: Add virtio over mmio transport driver test: dm: blk: Correct blk_base test case sandbox: blk: Switch to use platdata_auto_alloc_size for the driver data efi_driver: blk: Switch to use platdata_auto_alloc_size for the driver data blk: Call part_init() in the post_probe() method blk: Drop blk_prepare_device() blk: Make blk_next_free_devnum() public riscv: qemu: Enumerate virtio bus during early boot riscv: qemu: Include some useful commands kconfig: Introduce HAVE_ARCH_IOMAP x86: Implement arch-specific io accessor routines virtio: Add virtio over pci transport driver arm: qemu: Add a Kconfig in the board directory arm: qemu: Enumerate virtio bus during early boot x86: qemu: Imply virtio PCI transport and device drivers dm: pci: Add APIs to find next capability and extended capability test: dm: pci: Add cases for finding next PCI capability APIs virtio: pci: Support non-legacy PCI transport device virtio: net: Support non-legacy device virtio: Add a Sandbox transport driver test: dm: virtio: Add test cases for virtio uclass doc: Document virtio support Tuomas Tynkkynen (5): virtio: Add codes for virtual queue/ring management virtio: Add net driver support blk: Introduce IF_TYPE_VIRTIO virtio: Add block driver support virtio: cmd: Add virtio command for virtio devices arch/Kconfig | 6 + arch/arm/Kconfig | 1 + arch/riscv/lib/bootm.c | 11 +- arch/sandbox/dts/test.dts | 8 + arch/x86/include/asm/io.h | 66 +++ board/emulation/qemu-arm/Kconfig | 13 + board/emulation/qemu-arm/qemu-arm.c | 10 + board/emulation/qemu-riscv/Kconfig | 11 + board/emulation/qemu-riscv/qemu-riscv.c | 9 + board/emulation/qemu-x86/Kconfig | 3 + cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/sata.c | 9 - cmd/virtio.c | 38 ++ common/usb_storage.c | 4 +- configs/qemu_arm64_defconfig | 1 - configs/qemu_arm_defconfig | 1 - configs/sandbox_noblk_defconfig | 1 + disk/part.c | 6 + doc/README.virtio | 253 ++++++++++++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/block/blk-uclass.c | 25 +- drivers/block/ide.c | 2 - drivers/block/sandbox.c | 17 +- drivers/core/uclass.c | 13 +- drivers/misc/swap_case.c | 9 + drivers/mmc/mmc.c | 3 - drivers/nvme/nvme.c | 1 - drivers/pci/pci-uclass.c | 51 ++- drivers/scsi/scsi.c | 1 - drivers/virtio/Kconfig | 62 +++ drivers/virtio/Makefile | 11 + drivers/virtio/virtio-uclass.c | 369 +++++++++++++++++ drivers/virtio/virtio_blk.c | 137 +++++++ drivers/virtio/virtio_blk.h | 129 ++++++ drivers/virtio/virtio_mmio.c | 413 +++++++++++++++++++ drivers/virtio/virtio_mmio.h | 129 ++++++ drivers/virtio/virtio_net.c | 239 +++++++++++ drivers/virtio/virtio_net.h | 268 ++++++++++++ drivers/virtio/virtio_pci.h | 173 ++++++++ drivers/virtio/virtio_pci_legacy.c | 421 +++++++++++++++++++ drivers/virtio/virtio_pci_modern.c | 609 +++++++++++++++++++++++++++ drivers/virtio/virtio_ring.c | 358 ++++++++++++++++ drivers/virtio/virtio_sandbox.c | 233 +++++++++++ include/blk.h | 22 +- include/dm/test.h | 1 + include/dm/uclass-id.h | 1 + include/dm/uclass.h | 4 +- include/linux/io.h | 4 + include/pci.h | 48 +++ include/virtio.h | 707 ++++++++++++++++++++++++++++++++ include/virtio_ring.h | 320 +++++++++++++++ include/virtio_types.h | 24 ++ lib/Kconfig | 6 + lib/efi_driver/efi_block_device.c | 26 +- test/dm/Makefile | 1 + test/dm/blk.c | 27 +- test/dm/bus.c | 45 ++ test/dm/pci.c | 20 + test/dm/test-fdt.c | 7 +- test/dm/virtio.c | 122 ++++++ 62 files changed, 5421 insertions(+), 99 deletions(-) create mode 100644 board/emulation/qemu-arm/Kconfig create mode 100644 cmd/virtio.c create mode 100644 doc/README.virtio create mode 100644 drivers/virtio/Kconfig create mode 100644 drivers/virtio/Makefile create mode 100644 drivers/virtio/virtio-uclass.c create mode 100644 drivers/virtio/virtio_blk.c create mode 100644 drivers/virtio/virtio_blk.h create mode 100644 drivers/virtio/virtio_mmio.c create mode 100644 drivers/virtio/virtio_mmio.h create mode 100644 drivers/virtio/virtio_net.c create mode 100644 drivers/virtio/virtio_net.h create mode 100644 drivers/virtio/virtio_pci.h create mode 100644 drivers/virtio/virtio_pci_legacy.c create mode 100644 drivers/virtio/virtio_pci_modern.c create mode 100644 drivers/virtio/virtio_ring.c create mode 100644 drivers/virtio/virtio_sandbox.c create mode 100644 include/virtio.h create mode 100644 include/virtio_ring.h create mode 100644 include/virtio_types.h create mode 100644 test/dm/virtio.c -- 2.7.4

4 73

Re: [U-Boot] [PATCH u-boot-marvell v3 09/10] board: turris_mox: Support 1 GB version of Turris Mox
by Marek Behun 13 Dec '18

13 Dec '18

Hi, I have found the bug causing this issue. If I understand the algorithm in get_ram_size correctly, it does approximately this. Suppose A, B, C, D, E, F are different constatnts. X(i) is a value at address 1<<i (couting in longs). save[5] <- X(5) X(5) <- F save[4] <- X(4) X(4) <- E save[3] <- X(3) X(3) <- D save[2] <- X(2) X(2) <- C save[1] <- X(1) X(1) <- B save[0] <- X(0) X(0) <- A So the previous values are stored in array save[]. The algorithm then checks if the values written (the constants A, B, C, D, E, F) are present at those addresses. The problem is that the previous value from save[] is written during checking of address i: Now suppose the RAM is wrapped similarily as in MOX, so that X(i+3) is the same as X(i). After the first part, the values are as follows X([0,1,2,3,4,5]) = [A,B,C,A,B,C] save = [D,E,F,_3,_4,_5] Here _3, _4, _5 are the values at addresses X(3), X(4), X(5) before the algorithm. The code that checks the values written does this: if X(0) != A return 0 X(0) <- save[0] !!! this also writes D to X(3) if X(1) != B return 1 X(1) <- save[1] !!! this also writes E to X(4) if X(2) != C return 2 X(2) <- save[2] !!! this also writes F to X(F) if X(3) != D return 3 !!! this should return, but won't X(3) <- save[3] ... One solution would be to write the previous values from the array save[] only immediately before return from the function. I have to confess that I do not like how this function is written at all. It does not, for example, solve correctly the case when a device has 768 MiB of RAM from two chips (512 + 256). Given 1024 MiB as argument, it would return 1024 MiB, but the system only has 768 MiB. This maybe is never an issue with devices that run u-boot, but still. Marek On Tue, 11 Dec 2018 16:06:42 +0100 Stefan Roese <sr(a)denx.de> wrote: > On 11.12.18 15:53, Marek Behún wrote: > > On Tue, 11 Dec 2018 15:28:11 +0100 > > Stefan Roese <sr(a)denx.de> wrote: > > > >> Hi Marek, > >> > >> On 11.12.18 14:59, Marek Behún wrote: > >>> get_ram_size does not work correctly on Mox. On a 512 MiB board it > >>> detects 1024 MiB of RAM, because on the 512 MiB RAM chip the > >>> topmost address bit is simply ignored and the RAM wraps - on > >>> 0x20000000-0x40000000 CPU sees the same data as on > >>> 0x0-0x20000000. > >> > >> That's what get_ram_size() does: It does detect such aliases when > >> the same memory is mapped at multiple areas (power of 2). Did you > >> give it a try with a max value of 1024 MiB? It should return > >> 512 on such boards. > > > > I checked it and it returned 1024 MiB. > > I did > > printf("%08x %08x\n", > > get_ram_size(0, 512<<20), > > get_ram_size(0, 1024<<20)); > > on a 512 MiB board and > > 0x20000000 0x40000000 > > was printed. > > Very strange. Could you please debug this issue? get_ram_size() > should be able to work in such situations. > > Thanks, > Stefan > > >> > >>> ATF does not run RAM size determining code either, it just gets > >>> RAM size from a register, this register is written before ATF by > >>> BootROM and we have done it so that there is always 1 GB so that > >>> we could use same secure firmware image for all Moxes. I tried to > >>> change this register in secure firmware, but this lead to > >>> Synchornous Abort events in U-Boot. > >>> > >>> Maybe we could move the dram_init funcitons from arm64-common.c to > >>> specific board files, or maybe we could declare them __weak in > >>> arm64-common.c and turris_mox can then redefine them. > >>> > >>> Would that be OK with you? > >> > >> Please fist check if get_ram_size() can't be used. > >> > >> Thanks, > >> Stefan > >> > >>> Marek > >>> > >>> On Thu, 29 Nov 2018 14:07:59 +0100 > >>> Stefan Roese <sr(a)denx.de> wrote: > >>> > >>>> On 20.11.18 13:04, Marek Behún wrote: > >>>>> Depending on the data in the OTP memory, differentiate between > >>>>> the 512 MiB and 1 GiB versions of Turris Mox and report these > >>>>> RAM sizes in dram_init and dram_init_banksize. > >>>>> > >>>>> Signed-off-by: Marek Behún <marek.behun(a)nic.cz> > >>>>> --- > >>>>> arch/arm/mach-mvebu/arm64-common.c | 7 ++++++- > >>>>> board/CZ.NIC/turris_mox/turris_mox.c | 27 > >>>>> +++++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 1 > >>>>> deletion(-) > >>>>> > >>>>> diff --git a/arch/arm/mach-mvebu/arm64-common.c > >>>>> b/arch/arm/mach-mvebu/arm64-common.c index > >>>>> f47273fde9..5e6ac9fc4a 100644 --- > >>>>> a/arch/arm/mach-mvebu/arm64-common.c +++ > >>>>> b/arch/arm/mach-mvebu/arm64-common.c @@ -43,8 +43,12 @@ const > >>>>> struct mbus_dram_target_info *mvebu_mbus_dram_info(void) return > >>>>> NULL; } > >>>>> > >>>>> -/* DRAM init code ... */ > >>>>> +/* > >>>>> + * DRAM init code ... > >>>>> + * Turris Mox defines this itself, depending on data in burned > >>>>> eFuses > >>>>> + */ > >>>>> > >>>>> +#ifndef CONFIG_TARGET_TURRIS_MOX > >>>>> int dram_init_banksize(void) > >>>>> { > >>>>> fdtdec_setup_memory_banksize(); > >>>>> @@ -59,6 +63,7 @@ int dram_init(void) > >>>>> > >>>>> return 0; > >>>>> } > >>>>> +#endif /* !CONFIG_TARGET_TURRIS_MOX */ > >>>> > >>>> 2 Problems with this: > >>>> > >>>> a) > >>>> This does not apply any more with the latest changes in mainline. > >>>> > >>>> b) > >>>> I really don't like #ifdef's here in this common code. Can you > >>>> not get rid of this somehow? Isn't the turris_mox also using ATF > >>>> and will read the RAM size from there? > >>>> > >>>> U-Boot still has the good old get_ram_size() function, which can > >>>> easily auto-detect 512MiB vs 1GiB when run with 1GiB as > >>>> parameter. > >>>> > >>>> Thanks, > >>>> Stefan > >>>> > >>>>> > >>>>> int arch_cpu_init(void) > >>>>> { > >>>>> diff --git a/board/CZ.NIC/turris_mox/turris_mox.c > >>>>> b/board/CZ.NIC/turris_mox/turris_mox.c index > >>>>> 89b3cd2ce0..9aa2fc004d 100644 --- > >>>>> a/board/CZ.NIC/turris_mox/turris_mox.c +++ > >>>>> b/board/CZ.NIC/turris_mox/turris_mox.c @@ -14,6 +14,7 @@ > >>>>> #include <linux/string.h> > >>>>> #include <linux/libfdt.h> > >>>>> #include <fdt_support.h> > >>>>> +#include <environment.h> > >>>>> > >>>>> #ifdef CONFIG_WDT_ARMADA_37XX > >>>>> #include <wdt.h> > >>>>> @@ -40,6 +41,32 @@ > >>>>> > >>>>> DECLARE_GLOBAL_DATA_PTR; > >>>>> > >>>>> +int dram_init(void) > >>>>> +{ > >>>>> + int ret, ram_size; > >>>>> + > >>>>> + gd->ram_base = 0; > >>>>> + gd->ram_size = (phys_size_t)0x20000000; > >>>>> + > >>>>> + ret = mbox_sp_get_board_info(NULL, NULL, NULL, NULL, > >>>>> &ram_size); > >>>>> + if (ret < 0) { > >>>>> + puts("Cannot read RAM size from OTP, defaulting > >>>>> to 512 MiB"); > >>>>> + } else { > >>>>> + if (ram_size == 1024) > >>>>> + gd->ram_size = (phys_size_t)0x40000000; > >>>>> + } > >>>>> + > >>>>> + return 0; > >>>>> +} > >>>>> + > >>>>> +int dram_init_banksize(void) > >>>>> +{ > >>>>> + gd->bd->bi_dram[0].start = (phys_addr_t)0; > >>>>> + gd->bd->bi_dram[0].size = gd->ram_size; > >>>>> + > >>>>> + return 0; > >>>>> +} > >>>>> + > >>>>> #if defined(CONFIG_OF_BOARD_FIXUP) > >>>>> int board_fix_fdt(void *blob) > >>>>> { > >>>>> > >>>> > >>>> Viele Grüße, > >>>> Stefan > >>>> > >>> > >> > >> Viele Grüße, > >> Stefan > >> > > > > Viele Grüße, > Stefan >

2 3

Re: [U-Boot] [PATCH v5 06/25] riscv: ax25: Hide the ax25-specific Kconfig option
by Rick Chen 13 Dec '18

13 Dec '18

> > Subject: [PATCH v5 06/25] riscv: ax25: Hide the ax25-specific Kconfig option > > > > There is no need to expose RISCV_NDS to the Kconfig menu as it is an > > ax25-specific option. Introduce a dedicated Kconfig option for the cache ops of > > ax25 platform and use that to guard the cache ops. > > > > Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> > > > > --- > > > > Changes in v5: > > - Introduced another Kconfig option for the cache ops on AX25 CPU, > > so that it remains selectable in Kconfig menu, but only visible > > to AX25 platform. > > > > Changes in v4: None > > Changes in v3: None > > Changes in v2: None > > > > arch/riscv/cpu/ax25/Kconfig | 17 ++++++++++++----- > > arch/riscv/cpu/ax25/cache.c | 12 ++++++------ > > board/AndesTech/ax25-ae350/Kconfig | 4 ++++ > > 3 files changed, 22 insertions(+), 11 deletions(-) > > > > diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/ax25/Kconfig index > > 6c7022f..e9dbca2 100644 > > --- a/arch/riscv/cpu/ax25/Kconfig > > +++ b/arch/riscv/cpu/ax25/Kconfig > > @@ -1,7 +1,14 @@ > > config RISCV_NDS > > - bool "AndeStar V5 ISA support" > > - default n > > + bool > > help > > - Say Y here if you plan to run U-Boot on AndeStar v5 > > - platforms and use some specific features which are > > - provided by Andes Technology AndeStar V5 Families. > > + Run U-Boot on AndeStar V5 platforms and use some specific features > > + which are provided by Andes Technology AndeStar V5 families. > > + > > +if RISCV_NDS > > + > > +config RISCV_NDS_CACHE > > + bool "AndeStar V5 families specific cache support" > > + help > > + Provide Andes Technology AndeStar V5 families specific cache support. > > + > > +endif > > diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c index > > 6600ac2..8d6ae17 100644 > > --- a/arch/riscv/cpu/ax25/cache.c > > +++ b/arch/riscv/cpu/ax25/cache.c > > @@ -9,7 +9,7 @@ > > void icache_enable(void) > > { > > #ifndef CONFIG_SYS_ICACHE_OFF > > -#ifdef CONFIG_RISCV_NDS > > +#ifdef CONFIG_RISCV_NDS_CACHE > > asm volatile ( > > "csrr t1, mcache_ctl\n\t" > > "ori t0, t1, 0x1\n\t" > > @@ -22,7 +22,7 @@ void icache_enable(void) void icache_disable(void) > > { #ifndef CONFIG_SYS_ICACHE_OFF -#ifdef CONFIG_RISCV_NDS > > +#ifdef CONFIG_RISCV_NDS_CACHE > > asm volatile ( > > "fence.i\n\t" > > "csrr t1, mcache_ctl\n\t" > > @@ -36,7 +36,7 @@ void icache_disable(void) void dcache_enable(void) > > { #ifndef CONFIG_SYS_DCACHE_OFF -#ifdef CONFIG_RISCV_NDS > > +#ifdef CONFIG_RISCV_NDS_CACHE > > asm volatile ( > > "csrr t1, mcache_ctl\n\t" > > "ori t0, t1, 0x2\n\t" > > @@ -49,7 +49,7 @@ void dcache_enable(void) void dcache_disable(void) > > { #ifndef CONFIG_SYS_DCACHE_OFF -#ifdef CONFIG_RISCV_NDS > > +#ifdef CONFIG_RISCV_NDS_CACHE > > asm volatile ( > > "fence\n\t" > > "csrr t1, mcache_ctl\n\t" > > @@ -64,7 +64,7 @@ int icache_status(void) { > > int ret = 0; > > > > -#ifdef CONFIG_RISCV_NDS > > +#ifdef CONFIG_RISCV_NDS_CACHE > > asm volatile ( > > "csrr t1, mcache_ctl\n\t" > > "andi %0, t1, 0x01\n\t" > > @@ -81,7 +81,7 @@ int dcache_status(void) { > > int ret = 0; > > > > -#ifdef CONFIG_RISCV_NDS > > +#ifdef CONFIG_RISCV_NDS_CACHE > > asm volatile ( > > "csrr t1, mcache_ctl\n\t" > > "andi %0, t1, 0x02\n\t" > > diff --git a/board/AndesTech/ax25-ae350/Kconfig > > b/board/AndesTech/ax25-ae350/Kconfig > > index bb69ea3..44cb302 100644 > > --- a/board/AndesTech/ax25-ae350/Kconfig > > +++ b/board/AndesTech/ax25-ae350/Kconfig > > @@ -21,4 +21,8 @@ config ENV_SIZE > > config ENV_OFFSET > > default 0x140000 if ENV_IS_IN_SPI_FLASH > > > > +config BOARD_SPECIFIC_OPTIONS # dummy > > + def_bool y > > + select RISCV_NDS > > + > > endif Reviewed-by: Rick Chen <rick(a)andestech.com> > > -- > > 2.7.4 >

1 0

Re: [U-Boot] [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific Kconfig option
by Rick Chen 13 Dec '18

13 Dec '18

> > Subject: [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific Kconfig option > > > > There is no need to expose RISCV_NDS to the Kconfig menu as it is an > > ax25-specific option. > > Hi Bin Can you explain why there is no need to expose RISCV_NDS here ? Rick > > Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> > > --- > > > > Changes in v2: None > > > > arch/riscv/cpu/ax25/Kconfig | 8 +++----- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/ax25/Kconfig index > > 6c7022f..5ff9e5c 100644 > > --- a/arch/riscv/cpu/ax25/Kconfig > > +++ b/arch/riscv/cpu/ax25/Kconfig > > @@ -1,7 +1,5 @@ > > config RISCV_NDS > > - bool "AndeStar V5 ISA support" > > - default n > > + bool > > help > > - Say Y here if you plan to run U-Boot on AndeStar v5 > > - platforms and use some specific features which are > > - provided by Andes Technology AndeStar V5 Families. > > + Run U-Boot on AndeStar v5 platforms and use some specific features > > + which are provided by Andes Technology AndeStar V5 Families. > > -- > > 2.7.4 >

2 6

[U-Boot] qemu x86 ide device not probing automatically with 2018.11
by Joshua Watt 13 Dec '18

13 Dec '18

Hello, I've been using u-boot as the boot loader for x86 qemu and some custom (e.g. non-default) boot commands. I recently upgraded from u-boot 2018.01 to 2018.11 and now my boot command fails because it doesn't look like u-boot is loading the driver for the ide device from which I'm attempting to load files. For reference, I'm basically building the qemu-x86 config only with changes to the default boot scripts. Namely, I have: #define CONFIG_BOOTCOMMAND \ "ide dev ${bootpart}; " \ "if run loadbootenv; then " \ "run importbootenv; " \ "fi; " \ "run doboot; " The failure appears to occur when the script attempts to run "ide dev ${bootpart}", claiming the ide device doesn't exist. If I manually run the command "ide reset", and then "bootd" everything works fine, so I think this is being caused by the switch to using the device model for ide(?). I suspect this means that I need to make some changes to my boot command to get it to probe the ide driver, but I wanted to make sure I'm doing that the correct way. Should I simply add a "ide reset" as the first line of CONFIG_BOOTCOMMAND, or is there a more "correct" way to get u-boot to probe the driver? Thanks, -- Joshua Watt <JPEWhacker(a)gmail.com>

2 1