[U-Boot] [PATCH] arm64: zynqmp: Sync defconfigs in connection to DEFINE_TCM_OCM_MMAP
CONFIG_MP was added to Kconfig with enabling CONFIG_DEFINE_TCM_OCM_MMAP=y for zynqmp boards. This option is enabled by default that's why it shouldn't be in defconfig. Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 - configs/xilinx_zynqmp_zcu100_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 1 - configs/xilinx_zynqmp_zcu102_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu111_revA_defconfig | 1 - 17 files changed, 17 deletions(-) diff --git a/configs/xilinx_zynqmp_zc1232_revA_defconfig b/configs/xilinx_zynqmp_zc1232_revA_defconfig index b4a800406795..10f48965f487 100644 --- a/configs/xilinx_zynqmp_zc1232_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1232_revA_defconfig @@ -7,7 +7,6 @@ CONFIG_DEBUG_UART_BASE=0xff00 CONFIG_DEBUG_UART_CLOCK=1 # CONFIG_SPL_FAT_SUPPORT is not set # CONFIG_SPL_LIBDISK_SUPPORT is not set -CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1232-revA" CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/xilinx_zynqmp_zc1254_revA_defconfig b/configs/xilinx_zynqmp_zc1254_revA_defconfig index cd2214c26dd0..d0392516a079 100644 --- a/configs/xilinx_zynqmp_zc1254_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1254_revA_defconfig @@ -7,7 +7,6 @@ CONFIG_DEBUG_UART_BASE=0xff00 CONFIG_DEBUG_UART_CLOCK=1 # CONFIG_SPL_FAT_SUPPORT is not set # CONFIG_SPL_LIBDISK_SUPPORT is not set -CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1254-revA" CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/xilinx_zynqmp_zc1275_revA_defconfig b/configs/xilinx_zynqmp_zc1275_revA_defconfig index a4543fbacf03..c66b9c04387a 100644 --- a/configs/xilinx_zynqmp_zc1275_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1275_revA_defconfig @@ -7,7 +7,6 @@ CONFIG_DEBUG_UART_BASE=0xff00 CONFIG_DEBUG_UART_CLOCK=1 # CONFIG_SPL_FAT_SUPPORT is not set # CONFIG_SPL_LIBDISK_SUPPORT is not set -CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1275-revA" CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/xilinx_zynqmp_zc1275_revB_defconfig b/configs/xilinx_zynqmp_zc1275_revB_defconfig index 93be68f88248..b3a4bffcf656 100644 --- a/configs/xilinx_zynqmp_zc1275_revB_defconfig +++ b/configs/xilinx_zynqmp_zc1275_revB_defconfig @@ -8,7 +8,6 @@ CONFIG_DEBUG_UART_BASE=0xff00 CONFIG_DEBUG_UART_CLOCK=1 # CONFIG_SPL_FAT_SUPPORT is not set # CONFIG_SPL_LIBDISK_SUPPORT is not set -CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1275-revB" CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig index 725873366fff..3a65cd96fff2 100644 --- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig @@ -7,7 +7,6 @@ CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xff00 CONFIG_DEBUG_UART_CLOCK=1 CONFIG_ZYNQMP_USB=y -CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1751-xm015-dc1" CONFIG_DEBUG_UART=y CONFIG_AHCI=y diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig index f9246a1d921c..e5e719ded35b 100644 --- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig @@ -8,7 +8,6 @@ CONFIG_DEBUG_UART_CLOCK=1 # CONFIG_SPL_FAT_SUPPORT is not set # CONFIG_SPL_LIBDISK_SUPPORT is not set CONFIG_ZYNQMP_USB=y -CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1751-xm016-dc2" CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig b/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig index cd752f44c443..7e8b18097d61 100644 --- a/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig @@ -7,7 +7,6 @@ CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xff01 CONFIG_DEBUG_UART_CLOCK=1 CONFIG_ZYNQMP_USB=y -CONFIG_DEFINE_TCM_OCM_MMAP=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1751-xm017-dc3" CONFIG_DEBUG_UART=y CONFIG_AHCI=y diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig index
Re: [U-Boot] [RFC] arm: dts: am33xx: Sync DTS with Linux 4.16.11
Hi Felix, On Wednesday 11 July 2018 06:59 PM, Felix Brack wrote: > Hi Lokesh, many thanks for the feedback! > > On 10.07.2018 08:42, Lokesh Vutla wrote: >> Hi Felix, >> >> On Thursday 24 May 2018 02:32 PM, Felix Brack wrote: >>> Hello, >>> >>> I am working on a patch to synchronize the DTS files of the am33xx SoC >>> with those from Linux 4.16.11 (current stable). >>> >>> After some tiny modifications to the boards am335x-pdu001, am335x-evm, >>> am335x-rut, am437x-gp-evm and am43x-epos-evm buildman passes without any >>> warnings on the 46 am33xx based boards. This is required but not >>> sufficient at all. >>> >>> As I'm the maintainer of the am335x-pdu001 board I will use it to >>> illustrate a sample problem. >>> The am335x-pdu001 board uses the ns16550 driver which reads the property >>> from the DT. This property is required and must be set to a >>> value of 2, otherwise it would default to 0. >>> The am33xx.dtsi file currently used by U-Boot sets this property >>> correctly for all 6 uarts. The am33xx.dtsi file from Linux 4.16.11 >>> however does not define this property anymore. >>> For the am335x-pdu001 board the fix is trivial: just add the property >>> to the board and U-Boot specific am335xx-pdu001-u-boot.dtsi >>> file. >>> But this has a major drawback: only the am335x-pdu001 board gets fixed. >>> What about other boards requiring the property? >> >> I agree this is a problem. Also not all kernel drivers need this >> property as there are separate driver files for some of the compatibles. >> And few drivers has this property hard-coded. >> >>> The first idea that would probably come into mind is to put the property >>> into the SoC specific am33xx-u-boot.dtsi file. But this file >>> is ignored if a board specific file already exists. Hence this can not >>> be done. >> >> One solution I can think of is add a Kconfig entry >> CONFIG_SYS_NS16550_REG_SHIFT. A default value of 0 can be assigned for >> this and can be updated in as necessary. >> >> So when doing dev_read_u32_default for reg-shift, >> CONFIG_SYS_NS16550_REG_SHIFT can be passed as default instead of 0. This >> way no DTS files needs to be updated. >> > This sounds like a very good solution for the property. I'm > thinking about sending in a patch ... That would be great. Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
On 11.7.2018 22:13, Simon Glass wrote: > On 11 July 2018 at 08:41, Michal Simek wrote: >> Relocate watchdog ops as was done by: >> "dm: Add support for all targets which requires MANUAL_RELOC" >> (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) >> >> Signed-off-by: Michal Simek >> --- >> >> based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html >> >> --- >> drivers/watchdog/wdt-uclass.c | 23 +++ >> 1 file changed, 23 insertions(+) >> > > Reviewed-by: Simon Glass > > When will the toolchain be fixed? It is really several years back when I have looked at it last time but I think that toolchain is fixed for quite some time and only changes in microblaze u-boot code are needed but really I would have to check and start to play with it. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH] usb: dwc3: convert to livetree
On 11.7.2018 17:01, Marek Vasut wrote: > On 06/11/2018 11:39 AM, Vipul Kumar wrote: >> Update the DWC3 USB driver to support a live tree. >> >> Signed-off-by: Vipul Kumar > > What about systems which do not use live tree, does it work on those ? > They are not affected because headers are pointing to right functions. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] ls1021a: problem with errata A009007
Hello Ran Wang, I have ported successfully U-Boot to an ls1021a based board and works nice for the HW I have access to. Now the customer reports problems on his HW with SYS_FSL_ERRATUM_A009007 which is always activated. Board does not boot, and crashes in erratum_a009007() (Sorry I have no logs ... nor access to this HW) Disabling this function, and U-Boot boots ... Customer states/confirmed me, that he has the same HW ... On the board USB is not used. Any ideas hints what can be wrong here? Thanks in advance. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] UBI fixable bit-flip issue
On 12/07/18 15:22, Heiko Schocher wrote: Hello Mark, added Richard Weinberger to cc... Am 12.07.2018 um 02:28 schrieb Mark Spieth: Hi In the process of investigating a boot failure on one of our devices, the UBI: fixable bit-flip detected at PEB message was seen with the following behaviour during kernel load in u-boot. Read [2285568] bytes UBI: fixable bit-flip detected at PEB 415 UBI: schedule PEB 415 for scrubbing UBI: fixable bit-flip detected at PEB 415 UBI: fixable bit-flip detected at PEB 419 UBI: schedule PEB 419 for scrubbing UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: schedule PEB 420 for scrubbing UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 This repeats until reset. U boot is a patched version of 2010.06 supplied by the chip vendor. No newer version is available from the vendor to try. :-( Can you use current mainline ? It s hard to say something about a 8 year old vendor U-Boot version ... I know. I did look at the current 2018.07 and 2014.10 as comparison. There are many patches applied by the vendor so porting them with the large changes to driver structure would be difficult and time consuming. The vendor is Lantiq and the SDK is current (this year). The patches include the init eba/wl swap. What do you mean here? https://lists.denx.de/pipermail/u-boot/2013-January/143199.html This patch was already applied by the vendor. ubi_eba_init_scan() must be initialised before ubi_wl_init_scan() and in that baseline they were the wrong way around. There is only 1 other message chain for fixable bit flips (2011) and that was not useful for this problem. A more detailed log with debugging available follows: UBI: fixable bit-flip detected at PEB 419 UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 19, torture 0 UBI DBG: erase_worker: erase PEB 419 EC 19 UBI DBG: sync_erase: erase PEB 419, old EC 19 UBI DBG: do_sync_erase: erase PEB 419 UBI DBG: sync_erase: erased PEB 419, new EC 20 UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0 UBI DBG: ensure_wear_leveling: schedule scrubbing UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420 UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048 UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419 UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096 UBI: fixable bit-flip detected at PEB 420 UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419 UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048 UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096 UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096 UBI: fixable bit-flip detected at PEB 419 UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 20, torture 0 UBI DBG: erase_worker: erase PEB 419 EC 20 UBI DBG: sync_erase: erase PEB 419, old EC 20 UBI DBG: do_sync_erase: erase PEB 419 UBI DBG: sync_erase: erased PEB 419, new EC 21 UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0 UBI DBG: ensure_wear_leveling: schedule scrubbing UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420 UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048 UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419 UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096 UBI: fixable bit-flip detected at PEB 420 UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419 UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048 UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096 UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096 UBI: fixable bit-flip detected at PEB 419 Investigation showed that a read with correctable bit errors was done returning -EUCLEAN to the ubi read function. Having read https://lists.denx.de/pipermail/u-boot/2013-September/161961.html which details a workaround to not return EUCLEAN from the NAND reader unless the number of fixed bits returned was 75% of the total number of correctable bits was exceeded during the read. This was impleneted in
Re: [U-Boot] [PATCH v4 3/6] block: Add a function to find block device descriptor
On Wed, 2018-07-11 at 14:13 -0600, Simon Glass wrote:
> Hi Tien Fong,
>
> On 11 July 2018 at 08:23, Chee, Tien Fong
> wrote:
> >
> > On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> > >
> > > Hi Tien,
> > >
> > > On 6 July 2018 at 02:26, wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee
> > > >
> > > > Add a function to find the block device descriptor of the
> > > > parent
> > > > device.
> > > >
> > > > Signed-off-by: Tien Fong Chee
> > > > ---
> > > > drivers/block/blk-uclass.c | 23 +++
> > > > include/blk.h | 9 +
> > > > 2 files changed, 32 insertions(+)
> > > >
> > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-
> > > > uclass.c
> > > > index 9e0c823..facf527 100644
> > > > --- a/drivers/block/blk-uclass.c
> > > > +++ b/drivers/block/blk-uclass.c
> > > > @@ -132,6 +132,29 @@ struct blk_desc
> > > > *blk_get_devnum_by_typename(const char *if_typename, int
> > > > devnum)
> > > > }
> > > >
> > > > /**
> > > > + * blk_get_by_device() - Get the block device descriptor for
> > > > the
> > > > given device
> > > > + * @dev: Instance of a storage device
> > > > + *
> > > > + * Return: With block device descriptor on success , NULL if
> > > > there
> > > > is no such
> > > > + *block device.
> > > > + */
> > > > +struct blk_desc *blk_get_by_device(struct udevice *dev)
> > > > +{
> > > > + struct udevice *child_dev, *next;
> > > > +
> > > > + device_foreach_child_safe(child_dev, next, dev) {
> > > > + if (device_get_uclass_id(child_dev) !=
> > > > UCLASS_BLK)
> > > > + continue;
> > > > +
> > > > + return dev_get_uclass_platdata(child_dev);
> > > > + }
> > > > +
> > > > + debug("%s: No block device found\n", __func__);
> > > > +
> > > > + return NULL;
> > > > +}
> > > Is this different from blk_get_from_parent() ?
> > This new function would return block description.
> > blk_get_from_parents() would return child device.
> OK, but please implement your function by calling
> blk_get_from_parent(). There is no need to duplicate the logic.
>
> Also how about calling it blk_get_desc_from_parent() ?
Okay.
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] UBI fixable bit-flip issue
Hello Mark, added Richard Weinberger to cc... Am 12.07.2018 um 02:28 schrieb Mark Spieth: Hi In the process of investigating a boot failure on one of our devices, the UBI: fixable bit-flip detected at PEB message was seen with the following behaviour during kernel load in u-boot. Read [2285568] bytes UBI: fixable bit-flip detected at PEB 415 UBI: schedule PEB 415 for scrubbing UBI: fixable bit-flip detected at PEB 415 UBI: fixable bit-flip detected at PEB 419 UBI: schedule PEB 419 for scrubbing UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: schedule PEB 420 for scrubbing UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 This repeats until reset. U boot is a patched version of 2010.06 supplied by the chip vendor. No newer version is available from the vendor to try. :-( Can you use current mainline ? It s hard to say something about a 8 year old vendor U-Boot version ... The patches include the init eba/wl swap. What do you mean here? A more detailed log with debugging available follows: UBI: fixable bit-flip detected at PEB 419 UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 19, torture 0 UBI DBG: erase_worker: erase PEB 419 EC 19 UBI DBG: sync_erase: erase PEB 419, old EC 19 UBI DBG: do_sync_erase: erase PEB 419 UBI DBG: sync_erase: erased PEB 419, new EC 20 UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0 UBI DBG: ensure_wear_leveling: schedule scrubbing UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420 UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048 UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419 UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096 UBI: fixable bit-flip detected at PEB 420 UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419 UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048 UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096 UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096 UBI: fixable bit-flip detected at PEB 419 UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 20, torture 0 UBI DBG: erase_worker: erase PEB 419 EC 20 UBI DBG: sync_erase: erase PEB 419, old EC 20 UBI DBG: do_sync_erase: erase PEB 419 UBI DBG: sync_erase: erased PEB 419, new EC 21 UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0 UBI DBG: ensure_wear_leveling: schedule scrubbing UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420 UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048 UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419 UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096 UBI: fixable bit-flip detected at PEB 420 UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419 UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048 UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096 UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096 UBI: fixable bit-flip detected at PEB 419 Investigation showed that a read with correctable bit errors was done returning -EUCLEAN to the ubi read function. Having read https://lists.denx.de/pipermail/u-boot/2013-September/161961.html which details a workaround to not return EUCLEAN from the NAND reader unless the number of fixed bits returned was 75% of the total number of correctable bits was exceeded during the read. This was impleneted in this version of ubi in uboot 2010.06 and it does hide the bit-flip infinite issue since this is new NAND FLASH. The original 2010.06 implementation returns EUCLEAN for any number of fixable bit flips and thus causes the PEB move to the best free one (scrub mode in wear_leveling_worker). This fix is not a root cause fix though. Investigating further led to the following root cause solution. The following is AFAICT. When the scrubber chooses a PEB to move the from the free balanced tree. This tree is sorted by EC (erase count) and then by PEB number. The find_wl_entry call uses a max parameter of WL_FREE_MAX_DIFF which is 8192 in this config. So the
Re: [U-Boot] [PATCH v4 2/6] cmd: ubifs: Factor out some checking codes into cmd_ubifs_mount()
Hello tien.fong.chee, Am 06.07.2018 um 10:26 schrieb tien.fong.c...@intel.com: From: Tien Fong Chee cmd_ubifs_mount() function would be called directly instead of involving whole command machinery for mounting ubifs in generic firmware loader, so some checking codes need to be factored out into cmd_ubifs_mount() without breaking original functionality design. Signed-off-by: Tien Fong Chee Reviewed-by: Marek Vasut --- cmd/ubifs.c | 22 ++ include/ubi_uboot.h | 1 + 2 files changed, 15 insertions(+), 8 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/6] cmd: ubifs: Move ubifs_initialized checking into cmd_ubifs_umount()
Hello Tien.fong.chee Am 06.07.2018 um 10:25 schrieb tien.fong.c...@intel.com: From: Tien Fong Chee cmd_ubifs_umount() function would be called directly instead of involving whole command machinery in generic firmware loader, so checking on ubifs_initialized status need to be done in cmd_ubifs_umount() without breaking original functionality design. Signed-off-by: Tien Fong Chee Reviewed-by: Marek Vasut --- cmd/ubifs.c | 18 +- include/ubi_uboot.h | 1 + 2 files changed, 10 insertions(+), 9 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: Fix: Compile MCR instruction on ARM 32-bit only
MCR instruction only available in ARM 32-bit. So, compile MCR instruction
when ARM 32-bit is enabled.
Signed-off-by: Ley Foon Tan
---
arch/arm/mach-socfpga/board.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index cb6530f..26d84be 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -19,6 +19,7 @@
DECLARE_GLOBAL_DATA_PTR;
void s_init(void) {
+#ifndef CONFIG_ARM64
/*
* Preconfigure ACTLR, make sure Write Full Line of Zeroes is disabled.
* This is optional on CycloneV / ArriaV.
@@ -29,6 +30,7 @@ void s_init(void) {
"isb\n"
"dsb\n"
::"r"(0x0));
+#endif
}
/*
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: dts: socfpga: stratix10: Fix memory node
Commit 5dfd5607af2114047bd ("ARM: socfpga: Pull DRAM size from DT") get
memory size from DT. So, we need to update memory size in memory node.
Otherwise, it cause U-boot hang.
Signed-off-by: Ley Foon Tan
---
arch/arm/dts/socfpga_stratix10_socdk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
b/arch/arm/dts/socfpga_stratix10_socdk.dts
index c6ab0ae..6e8ddcd 100644
--- a/arch/arm/dts/socfpga_stratix10_socdk.dts
+++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
@@ -36,8 +36,8 @@
memory {
device_type = "memory";
- /* We expect the bootloader to fill in the reg */
- reg = <0 0 0 0>;
+ reg = <0 0 0 0x8000>; /* 2GB */
+ u-boot,dm-pre-reloc;
};
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arm: socfpga: Fixes: Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET
Commit bfc6bae8fa1f2d8a9c51548767b02f1a1e0ffe52 This commit rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET. Update with new CONFIG name. Signed-off-by: Ley Foon Tan Acked-by: Marek Vasut --- v2: - Rename commit title, add "Fixes:" tag - Add Acked-by from Marek --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 35b6ea2..4c60538 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -754,6 +754,7 @@ config ARCH_SOCFPGA select DM_SERIAL select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 select OF_CONTROL + select SPL_DM_RESET select SPL_LIBCOMMON_SUPPORT select SPL_LIBDISK_SUPPORT select SPL_LIBGENERIC_SUPPORT @@ -762,7 +763,6 @@ config ARCH_SOCFPGA select SPL_OF_CONTROL select SPL_SERIAL_SUPPORT select SPL_DM_SERIAL - select SPL_RESET_SUPPORT select SPL_SPI_FLASH_SUPPORT if SPL_SPI_SUPPORT select SPL_SPI_SUPPORT if DM_SPI select SPL_WATCHDOG_SUPPORT -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips
On Wed, Jul 11, 2018 at 06:35:33PM +0200, Daniel Schwierzeck wrote: > Hi Tom, > > Travis CI build: > https://travis-ci.org/danielschwierzeck/u-boot/builds/402636234 > > > The following changes since commit e3396ffd720877976141fa0b76a0b8ee9643d7d1: > > Merge git://git.denx.de/u-boot-dm (2018-07-10 10:29:14 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-mips.git master > > for you to fetch changes up to c38abed5093a486d6349fc0d9d7a663f24965d78: > > led: bcm6328: read base address in the parent node (2018-07-11 14:23:55 > +0200) > Applied to u-boot/master, thanks! -- 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] Please pull u-boot-dm
On Tue, Jul 10, 2018 at 02:58:16PM -0600, Simon Glass wrote: > Hi Tom, > > Here are some Python 3 fixes as mentioned on irc. I've left out the > two which cause problems. > > Travis run is here: > > https://travis-ci.org/sglass68/u-boot/builds/402281566 > > > The following changes since commit e3396ffd720877976141fa0b76a0b8ee9643d7d1: > > Merge git://git.denx.de/u-boot-dm (2018-07-10 10:29:14 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git > > for you to fetch changes up to 8793631ec13ee9e6c7189a7bdca38dde7b4390a8: > > test/py: vboot: Remove stderr redirect from openssl command > (2018-07-10 14:50:50 -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] UBI fixable bit-flip issue
Hi In the process of investigating a boot failure on one of our devices, the UBI: fixable bit-flip detected at PEB message was seen with the following behaviour during kernel load in u-boot. Read [2285568] bytes UBI: fixable bit-flip detected at PEB 415 UBI: schedule PEB 415 for scrubbing UBI: fixable bit-flip detected at PEB 415 UBI: fixable bit-flip detected at PEB 419 UBI: schedule PEB 419 for scrubbing UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: schedule PEB 420 for scrubbing UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 UBI: fixable bit-flip detected at PEB 420 UBI: fixable bit-flip detected at PEB 419 This repeats until reset. U boot is a patched version of 2010.06 supplied by the chip vendor. No newer version is available from the vendor to try. The patches include the init eba/wl swap. A more detailed log with debugging available follows: UBI: fixable bit-flip detected at PEB 419 UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 19, torture 0 UBI DBG: erase_worker: erase PEB 419 EC 19 UBI DBG: sync_erase: erase PEB 419, old EC 19 UBI DBG: do_sync_erase: erase PEB 419 UBI DBG: sync_erase: erased PEB 419, new EC 20 UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0 UBI DBG: ensure_wear_leveling: schedule scrubbing UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420 UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048 UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419 UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096 UBI: fixable bit-flip detected at PEB 420 UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419 UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048 UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096 UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096 UBI: fixable bit-flip detected at PEB 419 UBI DBG: schedule_erase: schedule erasure of PEB 419, EC 20, torture 0 UBI DBG: erase_worker: erase PEB 419 EC 20 UBI DBG: sync_erase: erase PEB 419, old EC 20 UBI DBG: do_sync_erase: erase PEB 419 UBI DBG: sync_erase: erased PEB 419, new EC 21 UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:0 UBI DBG: ensure_wear_leveling: schedule scrubbing UBI DBG: wear_leveling_worker: scrub PEB 420 to PEB 419 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 420 UBI DBG: ubi_io_read: read 2048 bytes from PEB 420:2048 UBI DBG: ubi_eba_copy_leb: copy LEB 6:11, PEB 420 to PEB 419 UBI DBG: ubi_eba_copy_leb: read 126976 bytes of data UBI DBG: ubi_io_read: read 126976 bytes from PEB 420:4096 UBI: fixable bit-flip detected at PEB 420 UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 419 UBI DBG: ubi_io_write: write 2048 bytes to PEB 419:2048 UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 419 UBI DBG: ubi_io_read: read 2048 bytes from PEB 419:2048 UBI DBG: ubi_io_write: write 126976 bytes to PEB 419:4096 UBI DBG: ubi_io_read: read 126976 bytes from PEB 419:4096 UBI: fixable bit-flip detected at PEB 419 Investigation showed that a read with correctable bit errors was done returning -EUCLEAN to the ubi read function. Having read https://lists.denx.de/pipermail/u-boot/2013-September/161961.html which details a workaround to not return EUCLEAN from the NAND reader unless the number of fixed bits returned was 75% of the total number of correctable bits was exceeded during the read. This was impleneted in this version of ubi in uboot 2010.06 and it does hide the bit-flip infinite issue since this is new NAND FLASH. The original 2010.06 implementation returns EUCLEAN for any number of fixable bit flips and thus causes the PEB move to the best free one (scrub mode in wear_leveling_worker). This fix is not a root cause fix though. Investigating further led to the following root cause solution. The following is AFAICT. When the scrubber chooses a PEB to move the from the free balanced tree. This tree is sorted by EC (erase count) and then by PEB number. The find_wl_entry call uses a max parameter of WL_FREE_MAX_DIFF which is 8192 in this config. So the find_wl_entry function will find a PEB that is better in error count that the current PEB EC. This can easily cause it to find the PEB that was just moved from if it is the lowest numbered PEB in the free tree. Waiting for
Re: [U-Boot] Please pull u-boot-dm
Hi Stephen, On 11 July 2018 at 16:01, Stephen Warren wrote: > On 07/10/2018 02:24 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 10 July 2018 at 13:53, Stephen Warren wrote: >>> >>> On 07/10/2018 12:47 PM, Tom Rini wrote: On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote: > Hi Tom. > > Here are some test-coverage and DM core enhancements. Also it adds a > way to access the binman definition from U-Boot. > > > The following changes since commit > 8c5d4fd0ec222701598a27b26ab7265d4cee45a3: > > Prepare v2018.07 (2018-07-09 10:24:14 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git > > for you to fetch changes up to > 16b8d6b76992690c65c58dc8b0591496cc5e46ef: > > binman: Support updating the device tree with calc'd info > (2018-07-09 09:11:00 -0600) >>> >>> >>> >>> This pull has caused intermittent/random build errors on my Jenkins >>> system. >>> The log shows: >>> LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPYspl/u-boot-spl.bin BINMAN u-boot-tegra.bin BINMAN u-boot-nodtb-tegra.bin BINMAN u-boot-dtb-tegra.bin binman: pylibfdt error -9: FDT_ERR_BADMAGIC /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/Makefile:1244: recipe for target 'u-boot-tegra.bin' failed make[1]: *** [u-boot-tegra.bin] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory '/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/build/u-boot/beaver' Makefile:148: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 make: Leaving directory '/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot' >>> >>> >>> >>> This doesn't happen every time; my Jenkins system builds 25 Tegra/sandbox >>> boards, yet a varying set of boards fail each time I trigger the build: >>> Just >>> beaver the first time, then just colibri_t20 and ventana, then just >>> medcom-wide. Note that the system performs incremental builds, if that >>> matters. >> >> >> That might be the fdt_resize() problem which David Gibson has just >> sorted out upstream. If you can run binman -D (to get a stack trace) >> that might help. I should be able to do a patch if that is the >> problem. > > > Is this the backtrace you're looking for? > >> [swarren@swarren-lx1 u-boot]$ >> CROSS_COMPILE=/home/swarren/shared/gcc-linaro-7.2.1-2017.11-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- >> sh -c "make O=build-beaver -s beaver_defconfig && make O=build-beaver -s >> -j8" >> arch/arm/dts/tegra30-apalis.dtb: Warning (avoid_unnecessary_addr_size): >> /i2c@7000d000/tps65911@2d/regulators: unnecessary #address-cells/#size-cells >> without "ranges" or child "reg" property >> arch/arm/dts/tegra30-beaver.dtb: Warning (avoid_unnecessary_addr_size): >> /i2c@7000d000/tps65911@2d/regulators: unnecessary #address-cells/#size-cells >> without "ranges" or child "reg" property >> binman: pylibfdt error -9: FDT_ERR_BADMAGIC >> >> Traceback (most recent call last): >> File "../tools/binman/binman", line 120, in RunBinman >> ret_code = control.Binman(options, args) >> File >> "/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/control.py", >> line 128, in Binman >> dtb = fdt.FdtScan(fname) >> File >> "/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", >> line 459, in FdtScan >> dtb = Fdt(fname) >> File >> "/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", >> line 315, in __init__ >> self._fdt_obj = libfdt.Fdt(fd.read()) >> File "scripts/dtc/pylibfdt/libfdt.py", line 207, in __init__ >> check_err(fdt_check_header(self._fdt)); >> File "scripts/dtc/pylibfdt/libfdt.py", line 160, in check_err >> raise FdtException(val) >> FdtException: pylibfdt error -9: FDT_ERR_BADMAGIC >> /home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/Makefile:1244: >> recipe for target 'u-boot-tegra.bin' failed >> make[1]: *** [u-boot-tegra.bin] Error 1 >> make[1]: *** Waiting for unfinished jobs Thanks for that. But actually that is not something I have seen or can explain. Here it is reading the DT at the start and somehow failing in the check. That DT is created by the U-Boot build system. Is it possible that your system has its own libfdt installed? As it happened, the pylibfdt changes have been applied upstream today, so I'll prepare a patch to sync U-Boot up with that. Hopefully that will resolve any issues, but I am not sure. [..] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 21/21] dt-bindings: Add bindings for SPI NAND devices
On Wed, 11 Jul 2018 17:25:29 +0200 Miquel Raynal wrote: > From: Boris Brezillon > > Add bindings for SPI NAND chips. > > Signed-off-by: Boris Brezillon > Signed-off-by: Miquel Raynal > --- > doc/device-tree-bindings/mtd/spi-nand.txt | 27 +++ > 1 file changed, 27 insertions(+) > create mode 100644 doc/device-tree-bindings/mtd/spi-nand.txt > > diff --git a/doc/device-tree-bindings/mtd/spi-nand.txt > b/doc/device-tree-bindings/mtd/spi-nand.txt > new file mode 100644 > index 00..d55f80196c > --- /dev/null > +++ b/doc/device-tree-bindings/mtd/spi-nand.txt > @@ -0,0 +1,27 @@ > +SPI NAND flash > + > +Required properties: > +- compatible: should be "spi-nand" > +- reg: should encode the chip-select line used to access the NAND chip > + > +Optional properties > +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate > at. > + This should encode board limitations (i.e. max freq can't > + be achieved due to crosstalk on IO lines). > + When unspecified, the driver assumes the chip can run at > + the max frequency defined in the spec (information > + extracted chip detection time). > +- spi-tx-bus-width: The bus width (number of data wires) that is used for > MOSI. > + Only encodes the board constraints (i.e. when not all IO > + signals are routed on the board). Device constraints are > + extracted when detecting the chip, and controller > + constraints are exposed by the SPI mem controller. If this > + property is missing that means no constraint at the board > + level. > +- spi-rx-bus-width: The bus width (number of data wires) that is used for > MISO. > + Only encodes the board constraints (i.e. when not all IO > + signals are routed on the board). Device constraints are > + extracted when detecting the chip, and controller > + constraints are exposed by the SPI mem controller. If this > + property is missing that means no constraint at the board > + level. This section has been dropped from the Linux doc. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 20/21] cmd: mtd: add 'mtd' command
On Wed, 11 Jul 2018 17:25:28 +0200
Miquel Raynal wrote:
> +
> +static void mtd_show_device(struct mtd_info *mtd)
> +{
> + printf("* %s", mtd->name);
Printing the device type might be interesting? And maybe also the size,
writesize, oobsize and erasesize?
> + if (mtd->dev)
> + printf(" [device: %s] [parent: %s] [driver: %s]",
> +mtd->dev->name, mtd->dev->parent->name,
> +mtd->dev->driver->name);
> +
> + printf("\n");
> +}
> +static int do_mtd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + struct mtd_info *mtd;
> + const char *cmd;
> + char *mtdname;
> + int ret;
> +
> + /* All MTD commands need at least two arguments */
> + if (argc < 2)
> + return CMD_RET_USAGE;
> +
> + /* Parse the command name and its optional suffixes */
> + cmd = argv[1];
> +
> + /* List the MTD devices if that is what the user wants */
> + if (strcmp(cmd, "list") == 0)
> + return do_mtd_list();
> +
> + /*
> + * The remaining commands require also at least a device ID.
> + * Check the selected device is valid. Ensure it is probed.
> + */
> + if (argc < 3)
> + return CMD_RET_USAGE;
> +
> + mtdname = argv[2];
> + mtd = get_mtd_device_nm(mtdname);
> + if (IS_ERR_OR_NULL(mtd)) {
> + mtd_probe_devices_dm();
> + mtd = get_mtd_device_nm(mtdname);
> + if (IS_ERR_OR_NULL(mtd)) {
> + printf("MTD device %s not found, ret %ld\n",
> +mtdname, PTR_ERR(mtd));
> + return 1;
> + }
> + }
> +
> + argc -= 3;
> + argv += 3;
> +
> + /* Do the parsing */
> + if (!strncmp(cmd, "read", 4) || !strncmp(cmd, "dump", 4) ||
> + !strncmp(cmd, "write", 5)) {
> + struct mtd_oob_ops io_op = {};
> + bool dump, read, raw, woob;
> + uint user_addr = 0;
> + uint nb_pages;
> + u8 *buf;
> + u64 off, len;
> + u32 oob_len;
> +
> + dump = !strncmp(cmd, "dump", 4);
> + read = dump || !strncmp(cmd, "read", 4);
> + raw = strstr(cmd, ".raw");
> + woob = strstr(cmd, ".oob");
> +
> + if (!dump) {
> + if (!argc)
> + return CMD_RET_USAGE;
> +
> + user_addr = simple_strtoul(argv[0], NULL, 16);
> + argc--;
> + argv++;
> + }
> +
> + off = argc > 0 ? simple_strtoul(argv[0], NULL, 16) : 0;
> + len = argc > 1 ? simple_strtoul(argv[1], NULL, 16) :
> mtd->writesize;
> + nb_pages = mtd_len_to_pages(mtd, len);
> + oob_len = woob ? nb_pages * mtd->oobsize : 0;
> +
> + if ((u32)off % mtd->writesize) {
> + printf("Offset not aligned with a page (0x%x)\n",
> +mtd->writesize);
> + return -EINVAL;
> + }
> +
> + if ((u32)len % mtd->writesize) {
> + printf("Size not a multiple of a page (0x%x)\n",
> +mtd->writesize);
> + return -EINVAL;
> + }
> +
> + if (dump)
> + buf = kmalloc(len + oob_len, GFP_KERNEL);
> + else
> + buf = map_sysmem(user_addr, 0);
> +
> + if (!buf) {
> + printf("Could not map/allocate the user buffer\n");
> + return -ENOMEM;
> + }
> +
> + printf("%s %lldB (%d page(s)) at offset 0x%08llx%s%s\n",
> +read ? "Reading" : "Writing", len, nb_pages, off,
> +raw ? " [raw]" : "", woob ? " [oob]" : "");
> +
> + io_op.mode = raw ? MTD_OPS_RAW : MTD_OPS_AUTO_OOB;
> + io_op.len = len;
> + io_op.ooblen = oob_len;
> + io_op.datbuf = buf;
> + io_op.oobbuf = woob ? [len] : NULL;
> +
> + if (read)
> + ret = mtd_read_oob(mtd, off, _op);
> + else
> + ret = mtd_write_oob(mtd, off, _op);
> +
> + if (ret) {
> + printf("%s on %s failed with error %d\n",
> +read ? "Read" : "Write", mtd->name, ret);
> + return ret;
> + }
> +
> + if (dump) {
> + uint page;
> +
> + for (page = 0; page < nb_pages; page++) {
> + u64 data_off = page * mtd->writesize;
> + printf("\nDump %d data bytes from 0x%08llx:\n",
> +mtd->writesize, data_off);
> + mtd_dump_buf(buf, mtd->writesize, data_off);
> +
> + if (woob) {
> +
Re: [U-Boot] [PATCH v2 09/21] mtd: move NAND fiels into a raw/ subdirectory
In your subject: s/fiels/files/ On Wed, 11 Jul 2018 17:25:17 +0200 Miquel Raynal wrote: > NAND flavors, like serial and parallel, have a lot in common and would > benefit to share code. Let's move raw (parallel) NAND specific code in a > raw/ subdirectory, to ease the addition of a core file in nand/ and the > introduction of a spi/ subdirectory specific to SPI NANDs. > > Signed-off-by: Miquel Raynal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/21] mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing
On Wed, 11 Jul 2018 17:25:12 +0200
Miquel Raynal wrote:
> Some MTD sublayers/drivers are implementing ->_read/write() and
> not ->_read/write_oob().
>
> While for NAND devices both are usually valid, for NOR devices, using
> the _oob variant has no real meaning. But, as the MTD layer is supposed
> to hide as much as possible the flash complexity to the user, there is
> no reason to error out while it is just a matter of rewritting things
> internally.
>
> Add a fallback on mtd->_read() (resp. mtd->_write()) when the user calls
> mtd_read_oob() (resp. mtd_write_oob()) while mtd->_read_oob() (resp.
> mtd->_write_oob) is not implemented. There is already a fallback on the
> _oob variant if the former is used.
Now I'm jealous. Can we have the same thing Linux :-).
>
> Signed-off-by: Miquel Raynal
> ---
> drivers/mtd/mtdcore.c | 26 --
> 1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index ba170f212e..095c58cf8c 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -1048,20 +1048,27 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from,
> struct mtd_oob_ops *ops)
> {
> int ret_code;
> ops->retlen = ops->oobretlen = 0;
> - if (!mtd->_read_oob)
> - return -EOPNOTSUPP;
>
> ret_code = mtd_check_oob_ops(mtd, from, ops);
> if (ret_code)
> return ret_code;
>
> + /* Check the validity of a potential fallback on mtd->_read */
> + if ((!mtd->_read_oob) && (!mtd->_read || ops->oobbuf))
Parens around !mtd->_read_oob are not needed.
> + return -EOPNOTSUPP;
> +
> + if (mtd->_read_oob)
> + ret_code = mtd->_read_oob(mtd, from, ops);
> + else
> + ret_code = mtd->_read(mtd, from, ops->len, >retlen,
> + ops->datbuf);
> +
> /*
>* In cases where ops->datbuf != NULL, mtd->_read_oob() has semantics
>* similar to mtd->_read(), returning a non-negative integer
>* representing max bitflips. In other cases, mtd->_read_oob() may
>* return -EUCLEAN. In all cases, perform similar logic to mtd_read().
>*/
> - ret_code = mtd->_read_oob(mtd, from, ops);
> if (unlikely(ret_code < 0))
> return ret_code;
> if (mtd->ecc_strength == 0)
> @@ -1076,8 +1083,7 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
> int ret;
>
> ops->retlen = ops->oobretlen = 0;
> - if (!mtd->_write_oob)
> - return -EOPNOTSUPP;
> +
> if (!(mtd->flags & MTD_WRITEABLE))
> return -EROFS;
>
> @@ -1085,7 +1091,15 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
> if (ret)
> return ret;
>
> - return mtd->_write_oob(mtd, to, ops);
> + /* Check the validity of a potential fallback on mtd->_write */
> + if ((!mtd->_write_oob) && (!mtd->_write || ops->oobbuf))
Ditto.
> + return -EOPNOTSUPP;
> +
> + if (mtd->_write_oob)
> + return mtd->_write_oob(mtd, to, ops);
> + else
> + return mtd->_write(mtd, to, ops->len, >retlen,
> +ops->datbuf);
> }
> EXPORT_SYMBOL_GPL(mtd_write_oob);
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
On 07/10/2018 02:24 PM, Simon Glass wrote: Hi Stephen, On 10 July 2018 at 13:53, Stephen Warren wrote: On 07/10/2018 12:47 PM, Tom Rini wrote: On Mon, Jul 09, 2018 at 01:53:43PM -0600, Simon Glass wrote: Hi Tom. Here are some test-coverage and DM core enhancements. Also it adds a way to access the binman definition from U-Boot. The following changes since commit 8c5d4fd0ec222701598a27b26ab7265d4cee45a3: Prepare v2018.07 (2018-07-09 10:24:14 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 16b8d6b76992690c65c58dc8b0591496cc5e46ef: binman: Support updating the device tree with calc'd info (2018-07-09 09:11:00 -0600) This pull has caused intermittent/random build errors on my Jenkins system. The log shows: LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPYspl/u-boot-spl.bin BINMAN u-boot-tegra.bin BINMAN u-boot-nodtb-tegra.bin BINMAN u-boot-dtb-tegra.bin binman: pylibfdt error -9: FDT_ERR_BADMAGIC /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/Makefile:1244: recipe for target 'u-boot-tegra.bin' failed make[1]: *** [u-boot-tegra.bin] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory '/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/build/u-boot/beaver' Makefile:148: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 make: Leaving directory '/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot' This doesn't happen every time; my Jenkins system builds 25 Tegra/sandbox boards, yet a varying set of boards fail each time I trigger the build: Just beaver the first time, then just colibri_t20 and ventana, then just medcom-wide. Note that the system performs incremental builds, if that matters. That might be the fdt_resize() problem which David Gibson has just sorted out upstream. If you can run binman -D (to get a stack trace) that might help. I should be able to do a patch if that is the problem. Is this the backtrace you're looking for? [swarren@swarren-lx1 u-boot]$ CROSS_COMPILE=/home/swarren/shared/gcc-linaro-7.2.1-2017.11-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- sh -c "make O=build-beaver -s beaver_defconfig && make O=build-beaver -s -j8" arch/arm/dts/tegra30-apalis.dtb: Warning (avoid_unnecessary_addr_size): /i2c@7000d000/tps65911@2d/regulators: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property arch/arm/dts/tegra30-beaver.dtb: Warning (avoid_unnecessary_addr_size): /i2c@7000d000/tps65911@2d/regulators: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property binman: pylibfdt error -9: FDT_ERR_BADMAGIC Traceback (most recent call last): File "../tools/binman/binman", line 120, in RunBinman ret_code = control.Binman(options, args) File "/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/control.py", line 128, in Binman dtb = fdt.FdtScan(fname) File "/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", line 459, in FdtScan dtb = Fdt(fname) File "/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/tools/binman/../dtoc/fdt.py", line 315, in __init__ self._fdt_obj = libfdt.Fdt(fd.read()) File "scripts/dtc/pylibfdt/libfdt.py", line 207, in __init__ check_err(fdt_check_header(self._fdt)); File "scripts/dtc/pylibfdt/libfdt.py", line 160, in check_err raise FdtException(val) FdtException: pylibfdt error -9: FDT_ERR_BADMAGIC /home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/Makefile:1244: recipe for target 'u-boot-tegra.bin' failed make[1]: *** [u-boot-tegra.bin] Error 1 make[1]: *** Waiting for unfinished jobs Section '/binman/image1': Symbol '_binman_u_boot_any_prop_pos' in entry '/binman/image1/u-boot-spl': insert _binman_u_boot_any_prop_pos, offset 592c, value 8011, length 4 Section '/binman/image1': Symbol '_binman_u_boot_any_prop_pos' in entry '/binman/image1/u-boot-spl': insert _binman_u_boot_any_prop_pos, offset 592c, value 8011, length 4 Section '/binman/image2': Symbol '_binman_u_boot_any_prop_pos' in entry '/binman/image2/u-boot-spl': insert _binman_u_boot_any_prop_pos, offset 592c, value 8011, length 4 Section '/binman/image2': Symbol '_binman_u_boot_any_prop_pos' in entry '/binman/image2/u-boot-spl': insert _binman_u_boot_any_prop_pos, offset 592c, value 8011, length 4 Section '/binman/image3': Symbol '_binman_u_boot_any_prop_pos' in entry '/binman/image3/u-boot-spl': insert _binman_u_boot_any_prop_pos, offset 592c, value 8011, length 4 Section '/binman/image3': Symbol '_binman_u_boot_any_prop_pos' in entry '/binman/image3/u-boot-spl': insert _binman_u_boot_any_prop_pos, offset 592c, value 8011, length 4 Makefile:148: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 ___ U-Boot mailing list
Re: [U-Boot] [PATCH 3/5] net: Make copy_filename() accept NULL src
> Am 11.07.2018 um 22:54 schrieb Joe Hershberger : > > Hey Alex, > >> On Thu, Jul 5, 2018 at 12:27 PM, Joe Hershberger >> wrote: >>> On Thu, Jul 5, 2018 at 6:49 AM, Alexander Graf wrote: On 07/04/2018 06:18 PM, Joe Hershberger wrote: > On Wed, Jul 4, 2018 at 4:25 AM, Alexander Graf wrote: > >> On 07/04/2018 02:36 AM, Joe Hershberger wrote: >> >> Rather than crashing, check the src ptr and set dst to empty string. >> >> Signed-off-by: Joe Hershberger > > > Wouldn't it make more sense to check for the existence outside at the > caller's side? That way it's much easier to see what really is happening. It's much easier to allow NULL so that we can directly pass the return result of getenv(). >>> >>> >>> I know, and I see how it looks insanely smart and simple today. Until you >>> realize that the amazing "copy_filename" function doesn't touch the target >>> at all if it gets passed in NULL. And all of that implicitly. So implicitly >>> it will leave the old value in the filename if nothing is set in env. >> >> I think you are mis-reading the code. If src is NULL, it will set >> dst[0] = '\0'; I think the behavior is quite reasonable. > > Do you have any outstanding issues with this? Nope, your call :) Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
Hi,
On Fri, Jun 22, 2018 at 02:25:34PM +0200, Jean-Jacques Hiblot wrote:
> +static int do_bind_unbind(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + int ret;
> + bool bind;
> + bool by_node;
> +
> + if (argc < 2)
> + return CMD_RET_USAGE;
> +
> + bind = (argv[0][0] == 'b');
> + by_node = (argv[1][0] == '/');
> +
> + if (by_node && bind) {
> + if (argc != 3)
> + return CMD_RET_USAGE;
> + ret = bind_by_node_path(argv[1], argv[2]);
> + } else if (by_node && !bind) {
> + if (argc != 2)
> + return CMD_RET_USAGE;
> + ret = unbind_by_node_path(argv[1]);
> + } else if (!by_node && bind) {
> + int index = (argc > 2) ? simple_strtoul(argv[2], NULL, 10) : 0;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> + ret = bind_by_class_index(argv[1], index, argv[3]);
> + } else if (!by_node && !bind) {
> + int index = (argc > 2) ? simple_strtoul(argv[2], NULL, 10) : 0;
> +
> + if (argc == 3)
> + ret = unbind_by_class_index(argv[1], index);
> + else if (argc == 4)
> + ret = unbind_child_by_class_index(argv[1], index,
> + argv[3]);
> + else
> + return CMD_RET_USAGE;
> + }
> +
> + if (ret)
FWIW, gcc 7.3.0 complains at this line:
cmd/bind.c: In function ‘do_bind_unbind’:
cmd/bind.c:236:5: warning: ‘ret’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (ret)
^
> + return CMD_RET_FAILURE;
> + else
> + return CMD_RET_SUCCESS;
> +}
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] net: Make copy_filename() accept NULL src
Hey Alex, On Thu, Jul 5, 2018 at 12:27 PM, Joe Hershberger wrote: > On Thu, Jul 5, 2018 at 6:49 AM, Alexander Graf wrote: >> On 07/04/2018 06:18 PM, Joe Hershberger wrote: >>> >>> On Wed, Jul 4, 2018 at 4:25 AM, Alexander Graf wrote: On 07/04/2018 02:36 AM, Joe Hershberger wrote: > > Rather than crashing, check the src ptr and set dst to empty string. > > Signed-off-by: Joe Hershberger Wouldn't it make more sense to check for the existence outside at the caller's side? That way it's much easier to see what really is happening. >>> >>> It's much easier to allow NULL so that we can directly pass the return >>> result of getenv(). >> >> >> I know, and I see how it looks insanely smart and simple today. Until you >> realize that the amazing "copy_filename" function doesn't touch the target >> at all if it gets passed in NULL. And all of that implicitly. So implicitly >> it will leave the old value in the filename if nothing is set in env. > > I think you are mis-reading the code. If src is NULL, it will set > dst[0] = '\0'; I think the behavior is quite reasonable. Do you have any outstanding issues with this? >> Imaging you're trying to read the code 4 years from now. Will you remember >> all of the side effects of copy_filename()? Imagine you're someone who's new >> to the code and doesn't know all the implicit side effects of its functions. >> Will you understand what is going on at a glimpse? > > That's an argument for documentation... and anyway, yes, I think the > function is sensible and I would expect it to do what it does. > > -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 4/8] clk: imx: imx6ul: Implement ENET clocks
On Mon, Jul 9, 2018 at 1:30 PM, Jagan Teki wrote: > Add support for ENET clock on i.MX6UL platform. > > Signed-off-by: Jagan Teki Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/6] block: Add a function to find block device descriptor
Hi Tien Fong,
On 11 July 2018 at 08:23, Chee, Tien Fong wrote:
> On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
>> Hi Tien,
>>
>> On 6 July 2018 at 02:26, wrote:
>> >
>> > From: Tien Fong Chee
>> >
>> > Add a function to find the block device descriptor of the parent
>> > device.
>> >
>> > Signed-off-by: Tien Fong Chee
>> > ---
>> > drivers/block/blk-uclass.c | 23 +++
>> > include/blk.h | 9 +
>> > 2 files changed, 32 insertions(+)
>> >
>> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-
>> > uclass.c
>> > index 9e0c823..facf527 100644
>> > --- a/drivers/block/blk-uclass.c
>> > +++ b/drivers/block/blk-uclass.c
>> > @@ -132,6 +132,29 @@ struct blk_desc
>> > *blk_get_devnum_by_typename(const char *if_typename, int devnum)
>> > }
>> >
>> > /**
>> > + * blk_get_by_device() - Get the block device descriptor for the
>> > given device
>> > + * @dev: Instance of a storage device
>> > + *
>> > + * Return: With block device descriptor on success , NULL if there
>> > is no such
>> > + *block device.
>> > + */
>> > +struct blk_desc *blk_get_by_device(struct udevice *dev)
>> > +{
>> > + struct udevice *child_dev, *next;
>> > +
>> > + device_foreach_child_safe(child_dev, next, dev) {
>> > + if (device_get_uclass_id(child_dev) != UCLASS_BLK)
>> > + continue;
>> > +
>> > + return dev_get_uclass_platdata(child_dev);
>> > + }
>> > +
>> > + debug("%s: No block device found\n", __func__);
>> > +
>> > + return NULL;
>> > +}
>> Is this different from blk_get_from_parent() ?
> This new function would return block description.
> blk_get_from_parents() would return child device.
OK, but please implement your function by calling
blk_get_from_parent(). There is no need to duplicate the logic.
Also how about calling it blk_get_desc_from_parent() ?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sandbox: Don't disable ctrlc() on sandbox if in raw mode
Hi Joe,
On 11 July 2018 at 13:32, Joe Hershberger wrote:
> On Tue, Jul 10, 2018 at 3:49 PM, Simon Glass wrote:
>> Hi Joe,
>>
>> On 9 July 2018 at 13:26, Joe Hershberger wrote:
>>> On Sun, Jul 8, 2018 at 9:39 PM, Simon Glass wrote:
Hi Joe,
On 2 July 2018 at 18:06, Joe Hershberger wrote:
> In raw mode, handle ctrl-c as normal. This allows normal ctrl-c behavior
> such as aborting a command that is timing out without completely
> terminating the sandbox executable.
>
> In [1], Simon disabled this. His reason for it was that it interferes
> with piping test scripts. Piping should be done in cooked mode, so this
> change should still not interfere.
>
> [1] commit 8969ea3e9f2db04a6b3675 ("sandbox: Disable Ctrl-C")
>
> Signed-off-by: Joe Hershberger
>
> ---
>
> common/console.c | 2 --
> drivers/serial/sandbox.c | 3 +++
> 2 files changed, 3 insertions(+), 2 deletions(-)
It is designed so that ctrl-C exits in raw mode. That is the normal
behaviour for an application and I don't think sandbox should be any
different.
How about using cooked mode instead?
>>>
>>> That seems backward. Only in raw mode (STATE_TERM_RAW) is the console
>>> not interfering with keyboard inputs and changing behaviors based on
>>> interpreting control codes. In raw mode, U-Boot sandbox can handle
>>> things the way it does in real hardware.
>>>
>>> To be clear, this is not the default case (STATE_TERM_RAW_WITH_SIGS)
>>> where ctrl-C exits. In fully raw mode (STATE_TERM_RAW), ctrl-C does
>>> absolutely nothing without this patch.
>>>
>>> Also, if cooked mode were used, it would once again break the test
>>> script piping that your previous commit talked about. I'm not sure
>>> exactly what that applies to (would it affect Travis such that I can
>>> validate interference?) so I'm not sure I've tested that use-case
>>> effectively.
>>
>> Er yes, sorry, I mean raw mode. I misunderstood your commit message I think.
>>
>> Reviewed-by: Simon Glass
>
> You want to take this series in or should I?
Please go ahead.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] microblaze: Do not call timer init that early
Hi Michal, On 11 July 2018 at 08:32, Michal Simek wrote: > Timer needs to be converted to DM but as of now it can't be called so > early because intc controller is not ready. Call it later in board_r.c. > Before this patch timer_init is called twice which is wrong. > > Signed-off-by: Michal Simek > --- > > common/board_f.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Instead of this, can you change your timer_init() function to check GD_FLG_RELOC in gd->flags and decide whether to init now or later? We want to get rid of all arch-specific #ifdefs in board_f/r.c Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
Hi Tien,
On 6 July 2018 at 02:28, wrote:
> From: Tien Fong Chee
>
> This is file system generic loader which can be used to load
> the file image from the storage into target such as memory.
> The consumer driver would then use this loader to program whatever,
> ie. the FPGA device.
>
> Signed-off-by: Tien Fong Chee
> ---
> drivers/misc/Kconfig | 10 ++
> drivers/misc/Makefile| 1 +
> drivers/misc/fs_loader.c | 295
> +++
> include/dm/uclass-id.h | 1 +
> include/fs_loader.h | 79 +
> 5 files changed, 386 insertions(+)
> create mode 100644 drivers/misc/fs_loader.c
> create mode 100644 include/fs_loader.h
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 17b3a80..4163b4f 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> depends on MISC
> help
> Support gdsys FPGA's RXAUI control.
> +
> +config FS_LOADER
> + bool "Enable loader driver for file system"
> + help
> + This is file system generic loader which can be used to load
> + the file image from the storage into target such as memory.
*a* file image?
> +
> + The consumer driver would then use this loader to program whatever,
> + ie. the FPGA device.
e.g. an FPGA device
> +
> endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 4ce9d21..67a36f8 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> new file mode 100644
> index 000..5fe642b
> --- /dev/null
> +++ b/drivers/misc/fs_loader.c
> @@ -0,0 +1,295 @@
> +/*
> + * Copyright (C) 2018 Intel Corporation
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct firmware_priv {
> + const char *name; /* Filename */
> + u32 offset; /* Offset of reading a file */
I don't understand that comment. Is it the offset within the file to
read from? Please can you expand it a bit?
> +};
> +
> +#ifdef CONFIG_CMD_UBIFS
> +static int mount_ubifs(char *mtdpart, char *ubivol)
> +{
> + int ret = ubi_part(mtdpart, NULL);
> +
> + if (ret) {
> + debug("Cannot find mtd partition %s\n", mtdpart);
> + return ret;
> + }
> +
> + return cmd_ubifs_mount(ubivol);
> +}
> +
> +static int umount_ubifs(void)
> +{
> + return cmd_ubifs_umount();
> +}
> +#else
> +static int mount_ubifs(char *mtdpart, char *ubivol)
> +{
> + debug("Error: Cannot load image: no UBIFS support\n");
blank line here
> + return -ENOSYS;
> +}
> +#endif
> +
> +static int select_fs_dev(struct device_platdata *plat)
> +{
> + int ret;
> +
> + if (plat->phandlepart.phandle) {
> + ofnode node;
> +
> + node = ofnode_get_by_phandle(plat->phandlepart.phandle);
> +
> + int of_offset = ofnode_to_offset(node);
> +
> + struct udevice *dev;
> +
> + ret = device_get_global_by_of_offset(of_offset, );
Can you please create device_get_global_by_ofnode() and use that
instead? We should not use offsets in new code.
> + if (!ret) {
> + struct blk_desc *desc = blk_get_by_device(dev);
> + if (desc) {
> + ret = fs_set_blk_dev_with_part(desc,
> + plat->phandlepart.partition);
> + } else {
> + debug("%s: No device found\n", __func__);
> + return -ENODEV;
> + }
> + }
> + } else if (plat->mtdpart && plat->ubivol) {
> + ret = mount_ubifs(plat->mtdpart, plat->ubivol);
> + if (ret)
> + return ret;
> +
> + ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
> + } else {
> + debug("Error: unsupported storage device.\n");
> + return -ENODEV;
> + }
> +
> + if (ret)
> + debug("Error: could not access storage.\n");
> +
> + return ret;
> +}
> +
> +/**
> + * _request_firmware_prepare - Prepare firmware struct.
> + *
> + * @name: Name of firmware file.
> + * @dbuf: Address of buffer to load firmware into.
> + * @size: Size of buffer.
> + * @offset: Offset of a file for start reading into buffer.
> + * @firmwarep: Pointer to pointer to firmware image.
> + *
> + * Return: Negative value
Re: [U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
On 11 July 2018 at 08:41, Michal Simek wrote: > Relocate watchdog ops as was done by: > "dm: Add support for all targets which requires MANUAL_RELOC" > (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) > > Signed-off-by: Michal Simek > --- > > based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html > > --- > drivers/watchdog/wdt-uclass.c | 23 +++ > 1 file changed, 23 insertions(+) > Reviewed-by: Simon Glass When will the toolchain be fixed? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
Hi, On 11 July 2018 at 07:40, Tom Rini wrote: > > On Wed, Jul 11, 2018 at 03:31:39PM +0200, Michal Simek wrote: > > On 11.7.2018 14:46, Tom Rini wrote: > > > On Wed, Jul 11, 2018 at 07:57:13AM +0200, Michal Simek wrote: > > >> On 10.7.2018 18:40, Tom Rini wrote: > > >>> On Mon, Jul 09, 2018 at 11:59:57AM -0500, Joe Hershberger wrote: > > On Mon, Jul 9, 2018 at 9:43 AM, Tom Rini wrote: > > > On Mon, Jul 09, 2018 at 08:19:44AM +0200, Michal Simek wrote: > > >> On 30.6.2018 06:19, Simon Glass wrote: > > >>> On 27 June 2018 at 07:13, Michal Simek > > >>> wrote: > > On 22.6.2018 14:25, Jean-Jacques Hiblot wrote: > > > In some cases it can be useful to be able to bind a device to a > > > driver from > > > the command line. > > > The obvious example is for versatile devices such as USB gadget. > > > Another use case is when the devices are not yet ready at startup > > > and > > > require some setup before the drivers are bound (ex: FPGA which > > > bitsream is > > > fetched from a mass storage or ethernet) > > > > > > usage example: > > > > > > bind usb_dev_generic 0 usb_ether > > > unbind usb_dev_generic 0 usb_ether > > > or > > > unbind eth 1 > > > > > > bind /ocp/omap_dwc3@4838/usb@4839 usb_ether > > > unbind /ocp/omap_dwc3@4838/usb@4839 > > > > > > Signed-off-by: Jean-Jacques Hiblot > > > > > > --- > > > > > > Changes in v3: > > > - factorize code based on comments from ML > > > - remove the devices before unbinding them > > > - use device_find_global_by_ofnode() to get a device by its node. > > > - Added tests > > > > > > Changes in v2: > > > - Make the bind/unbind command generic, not specific to usb > > > device. > > > - Update the API to be able to bind/unbind based on DTS node path > > > - Add a Kconfig option to select the bind/unbind commands > > > > > > arch/sandbox/dts/test.dts | 11 ++ > > > cmd/Kconfig| 9 ++ > > > cmd/Makefile | 1 + > > > cmd/bind.c | 255 > > > + > > > configs/sandbox_defconfig | 1 + > > > test/py/tests/test_bind.py | 178 +++ > > > 6 files changed, 455 insertions(+) > > > create mode 100644 cmd/bind.c > > > create mode 100644 test/py/tests/test_bind.py > > >>> > > >>> Reviewed-by: Simon Glass > > >>> > > >>> Nice work > > >>> > > >>> [...] > > >>> > > > > I have tested bind/unbind with dwc3 on zynqmp for ethernet gadget > > and it > > is working fine for me. > > I have also tried to use bind/unbind for gpio zynqmp driver and it > > is > > also working fine. > > > > It means > > Tested-by: Michal Simek > > > > I would prefer if these commands are called as dm bind and dm > > unbind > > instead of simply bind/unbind which should also fit to dm command > > description "dm - Driver model low level access". > > >>> > > >>> Yes i can see the point. But after thinking about it, maybe it is > > >>> best > > >>> as it is? After all driver model is fundamental to U-Boot and it's > > >>> not > > >>> clear what else we might bind/unbind. > > >>> > > >>> I'd like to get other opinions here, too. > > >> > > >> Tom/Marek: Any opinion? > > > > > > I think dm bind/unbind makes sense, yes. "bind" and "unbind" are > > > pretty > > > generic terms and making it clear it's part of working "inside" of DM > > > to > > > hook/unhook things by making it a sub-command of dm sounds good. > > > Thanks! > > > > I agree with Simon here. I think bind and unbind won't have any > > plausible other meaning in U-Boot and DM is core to U-Boot > > functionality in the new world. I think it would be OK to have "dm > > bind" alias to "bind" if that's a point of confusion, but having it > > top-level seems good to me. > > >>> > > >>> They're still very generic words for something that's part of working > > >>> under the dm framework. That said, looking at test/dm/cmd_dm.c and that > > >>> it's supposed to be only for test/debug type work, yes, OK, I'll change > > >>> my mind. > > >> > > >> I would expect that almost everybody will enable CMD_DM where symbol is > > >> in cmd/Kconfig but implementation in test/dm/cmd_dm.c (it is a question > > >> if this is the right place for this file). > > > > > > It might well really belong as cmd/dm.c, but content wise it's debug > > > information that is also useful
Re: [U-Boot] [PATCH] watchdog: dm: Change uclass name to watchdog and enable DM_UC_FLAG_SEQ_ALIAS
On 11 July 2018 at 00:45, Michal Simek wrote:
> uclass name is used by dev_read_alias_seq which return seq number when
> aliases are used.
>
> Code fragment:
> 168 int dev_read_alias_seq(struct udevice *dev, int *devnump)
> 169 {
> 170 ofnode node = dev_ofnode(dev);
> 171 const char *uc_name = dev->uclass->uc_drv->name;
> 172 int ret;
> 173
> 174 if (ofnode_is_np(node)) {
> 175 ret = of_alias_get_id(ofnode_to_np(node), uc_name);
>
> Also this patch enables DM_UC_FLAG_SEQ_ALIAS to be in sync with Linux
> which is also using watchdog name for watchdog aliases.
>
> drivers/watchdog/watchdog_core.c:215:
> ret = of_alias_get_id(wdd->parent->of_node, "watchdog");
>
> Signed-off-by: Michal Simek
> ---
>
> drivers/watchdog/wdt-uclass.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 6/8] net: fec_mxc: Add clock support via CLK
On Mon, Jul 9, 2018 at 1:30 PM, Jagan Teki wrote: > Now enet clock support available for imx6qdl and imx6ul, > via CLK framework, so add enable, set_rate support in > drivers. > > Signed-off-by: Jagan Teki Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 3/8] clk: imx: imx6q: Implement ENET clocks
On Mon, Jul 9, 2018 at 1:30 PM, Jagan Teki wrote: > Add support for ENET clock on i.MX6QDL platform. > > Signed-off-by: Jagan Teki Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sandbox: Don't disable ctrlc() on sandbox if in raw mode
On Tue, Jul 10, 2018 at 3:49 PM, Simon Glass wrote:
> Hi Joe,
>
> On 9 July 2018 at 13:26, Joe Hershberger wrote:
>> On Sun, Jul 8, 2018 at 9:39 PM, Simon Glass wrote:
>>> Hi Joe,
>>>
>>> On 2 July 2018 at 18:06, Joe Hershberger wrote:
In raw mode, handle ctrl-c as normal. This allows normal ctrl-c behavior
such as aborting a command that is timing out without completely
terminating the sandbox executable.
In [1], Simon disabled this. His reason for it was that it interferes
with piping test scripts. Piping should be done in cooked mode, so this
change should still not interfere.
[1] commit 8969ea3e9f2db04a6b3675 ("sandbox: Disable Ctrl-C")
Signed-off-by: Joe Hershberger
---
common/console.c | 2 --
drivers/serial/sandbox.c | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
>>>
>>> It is designed so that ctrl-C exits in raw mode. That is the normal
>>> behaviour for an application and I don't think sandbox should be any
>>> different.
>>>
>>> How about using cooked mode instead?
>>
>> That seems backward. Only in raw mode (STATE_TERM_RAW) is the console
>> not interfering with keyboard inputs and changing behaviors based on
>> interpreting control codes. In raw mode, U-Boot sandbox can handle
>> things the way it does in real hardware.
>>
>> To be clear, this is not the default case (STATE_TERM_RAW_WITH_SIGS)
>> where ctrl-C exits. In fully raw mode (STATE_TERM_RAW), ctrl-C does
>> absolutely nothing without this patch.
>>
>> Also, if cooked mode were used, it would once again break the test
>> script piping that your previous commit talked about. I'm not sure
>> exactly what that applies to (would it affect Travis such that I can
>> validate interference?) so I'm not sure I've tested that use-case
>> effectively.
>
> Er yes, sorry, I mean raw mode. I misunderstood your commit message I think.
>
> Reviewed-by: Simon Glass
You want to take this series in or should I?
Thanks,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] net: mvgbe: convert to DM
On Mon, Jul 9, 2018 at 4:34 AM, Chris Packham wrote: > Add driver model support to the mvgbe driver. As a temporary measure > both DM and non-DM uses are supported. Once all the users have been > converted the non-DM support can be dropped. > > Signed-off-by: Chris Packham Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 07/11/2018 07:30 PM, Trent Piepho wrote: > On Wed, 2018-07-11 at 08:56 -0500, Jason Rush wrote: >> On 7/11/2018 8:48 AM, Marek Vasut wrote: >>> On 07/11/2018 03:49 PM, Jason Rush wrote: My mistake. I did disable the dcache after scrubbing too. The code is almost identical to the Arria10 code where after scrubbing it flushes the dcache, then turns it off. The weird reset problems happens if I scrub the area where u-boot relocates to with the dcache on, then turn dcache off. I tried to also tried turning the MMU off, but that didn't help. >>> >>> Maybe there are some data used by the SPL there ? I think the SPL has >>> malloc area in RAM at some point. >>> >> >> I thought something similar, so I narrowed it down to clearing >> just from where U-Boot relocates to the end of DRAM. If I'm >> correct, that includes where U-Boot relocates and where the >> MMU tables are normally stored. > > I wonder if the reset does not properly reset the CPU caches? The idea > being that the CPU cache has stale data from before the reset, or maybe > just stale tag bits, and the hang is due to using this bad data from > the cache. That's why we do dcache_off() icache_off() first, to make sure the caches are in consistent state. But a good point nonetheless, this should be checked. > Or perhaps there is always something done incorrectly, but it is only > the state of DRAM after a reset, vs a power cycle, that consistently > triggers a hang? The SoCFPGA has some weird warm/cold reset hooks even in the bootrom, could be. But the DRAM should be torn down in either case. > If possible, try to add code before the hang point to invalidate both > the i-cache and d-cache for the problem region above. Perhaps the SPL > is doing something wrong w.r.t. cache invalidation, e.g. moving code > around and not updating the i-cache, because it assumes nothing has yet > used the caches, which is now no longer the case since you turn them on > for scrubbing. > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] net: zynq_gem: convert to use livetree
Hi Siva,
On Fri, Jul 6, 2018 at 5:10 AM, Siva Durga Prasad Paladugu
wrote:
> This patch updates the zynq gem driver to support
> livetree.
>
> Signed-off-by: Siva Durga Prasad Paladugu
> Signed-off-by: Vipul Kumar
> ---
> drivers/net/zynq_gem.c | 29 ++---
> 1 file changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index a817f2e..b9858e4 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -178,7 +178,7 @@ struct zynq_gem_priv {
> struct zynq_gem_regs *iobase;
> phy_interface_t interface;
> struct phy_device *phydev;
> - int phy_of_handle;
> + ofnode phy_of_node;
> struct mii_dev *bus;
> struct clk clk;
> u32 max_speed;
> @@ -349,8 +349,7 @@ static int zynq_phy_init(struct udevice *dev)
>
> priv->phydev->advertising = priv->phydev->supported;
>
> - if (priv->phy_of_handle > 0)
> - dev_set_of_offset(priv->phydev->dev, priv->phy_of_handle);
> + priv->phydev->dev->node = priv->phy_of_node;
>
> return phy_config(priv->phydev);
> }
> @@ -693,21 +692,23 @@ static int zynq_gem_ofdata_to_platdata(struct udevice
> *dev)
> {
> struct eth_pdata *pdata = dev_get_platdata(dev);
> struct zynq_gem_priv *priv = dev_get_priv(dev);
> - int node = dev_of_offset(dev);
> + struct ofnode_phandle_args phandle_args;
> const char *phy_mode;
>
> - pdata->iobase = (phys_addr_t)devfdt_get_addr(dev);
> + pdata->iobase = (phys_addr_t)dev_read_addr(dev);
> priv->iobase = (struct zynq_gem_regs *)pdata->iobase;
> /* Hardcode for now */
> priv->phyaddr = -1;
>
> - priv->phy_of_handle = fdtdec_lookup_phandle(gd->fdt_blob, node,
> - "phy-handle");
> - if (priv->phy_of_handle > 0)
> - priv->phyaddr = fdtdec_get_int(gd->fdt_blob,
> - priv->phy_of_handle, "reg", -1);
> + if (dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
> + _args)) {
> + debug("phy-handle does not exist %s\n", dev->name);
> + return -ENOENT;
> + }
>
> - phy_mode = fdt_getprop(gd->fdt_blob, node, "phy-mode", NULL);
> + priv->phyaddr = ofnode_read_u32_default(phandle_args.node, "reg", -1);
> + priv->phy_of_node = phandle_args.node;
> + phy_mode = dev_read_prop(dev, "phy-mode", NULL);
I want to make sure we are in sync here. I plan to take Grygorii's series.
Thanks!
> if (phy_mode)
> pdata->phy_interface = phy_get_interface_by_name(phy_mode);
> if (pdata->phy_interface == -1) {
> @@ -716,10 +717,8 @@ static int zynq_gem_ofdata_to_platdata(struct udevice
> *dev)
> }
> priv->interface = pdata->phy_interface;
>
> - priv->max_speed = fdtdec_get_uint(gd->fdt_blob, priv->phy_of_handle,
> - "max-speed", SPEED_1000);
> - priv->int_pcs = fdtdec_get_bool(gd->fdt_blob, node,
> - "is-internal-pcspma");
> + priv->max_speed = dev_read_u32_default(dev, "max-speed", SPEED_1000);
> + priv->int_pcs = dev_read_bool(dev, "is-internal-pcspma");
>
> printf("ZYNQ GEM: %lx, phyaddr %x, interface %s\n",
> (ulong)priv->iobase,
>priv->phyaddr, phy_string_for_interface(priv->interface));
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] net: phy: add ofnode node to struct phy_device
On Thu, Jul 5, 2018 at 12:02 PM, Grygorii Strashko wrote: > Now the UCLASS_ETH device "node" field is owerwritten by some network drivers > in > case of Ethernet PHYs which are linked to UCLASS_ETH device using > "phy-handle" DT property and when Ethernet PHY driver needs to read some > additional information from DT. In such cases following happens (in > general): > > - network drivers > priv->phydev = phy_connect(priv->bus, priv->phyaddr, dev, >priv->interface); > <-- phydev is connected to dev which is UCLASS_ETH device > > if (priv->phy_of_handle > 0) > dev_set_of_offset(priv->phydev->dev, priv->phy_of_handle); > <-- phydev->dev->node is overwritten by phy-handle DT node > > - PHY driver in .config() callback > int node = dev_of_offset(dev); > <-- PHY driver uses overwritten dev->node > const void *fdt = gd->fdt_blob; > > if (fdtdec_get_bool(fdt, node, "property")) > ... > > As result, UCLASS_ETH device can't be used any more for DT accessing. > > This patch adds additional ofnode node field to struct phy_device which can > be set explicitly by network drivers and used by PHY drivers, so > overwriting can be avoided. Also add helper function phy_get_ofnode() > which will check and return phy_device->node or dev_ofnode(phydev->dev) for > backward compatibility with existing drivers. > > Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
Since commit f2faffecb016, tegra: Convert to use binman
the dm-pre-reloc properties are removed.
This leads U-Boot not to enable the display on paz00
This patch restore the dm-pre-reloc properties allowing
the bootloader to output to the display panel
v4: - Spell project name as appropriate
v3: - Fix few typos
v2: - Add more characters to commit hash
Signed-off-by: Nicolas Chauvet
Reviewed-by: Simon Glass
---
arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/tegra20-u-boot.dtsi b/arch/arm/dts/tegra20-u-boot.dtsi
index 7c11972552..f64667e549 100644
--- a/arch/arm/dts/tegra20-u-boot.dtsi
+++ b/arch/arm/dts/tegra20-u-boot.dtsi
@@ -1,3 +1,13 @@
#include
#include "tegra-u-boot.dtsi"
+
+
+/ {
+ host1x@5000 {
+ u-boot,dm-pre-reloc;
+ dc@5420 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
Since commit f2faffecb016, tegra: Convert to use binman
the dm-pre-reloc properties are removed.
This leads uboot not to enable the display on paz00
This patch restore the dm-pre-reloc properties allowing
the bootloader to output to the display panel
v3: - Fix few typos
v2: - Add more characters to commit hash
Signed-off-by: Nicolas Chauvet
Reviewed-by: Simon Glass
---
arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/tegra20-u-boot.dtsi b/arch/arm/dts/tegra20-u-boot.dtsi
index 7c11972552..f64667e549 100644
--- a/arch/arm/dts/tegra20-u-boot.dtsi
+++ b/arch/arm/dts/tegra20-u-boot.dtsi
@@ -1,3 +1,13 @@
#include
#include "tegra-u-boot.dtsi"
+
+
+/ {
+ host1x@5000 {
+ u-boot,dm-pre-reloc;
+ dc@5420 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
On 11 July 2018 at 11:24, Nicolas Chauvet wrote:
> Since commit f2faffecb016, tegra: Convert to use binman
> the dm-pre-reloc properties are removed.
>
> This leads uboot not to enable the display on paz00
U-Boot :-)
>
> This patch restore the dm-pre-reloc properties allowing
> the bootloader to output to the display panel
>
> v3: - Fix few typos
> v2: - Add more characters to commit hash
>
> Signed-off-by: Nicolas Chauvet
> Reviewed-by: Simon Glass
> ---
> arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/dts/tegra20-u-boot.dtsi
> b/arch/arm/dts/tegra20-u-boot.dtsi
> index 7c11972552..f64667e549 100644
> --- a/arch/arm/dts/tegra20-u-boot.dtsi
> +++ b/arch/arm/dts/tegra20-u-boot.dtsi
> @@ -1,3 +1,13 @@
> #include
>
> #include "tegra-u-boot.dtsi"
> +
> +
> +/ {
> + host1x@5000 {
> + u-boot,dm-pre-reloc;
> + dc@5420 {
> + u-boot,dm-pre-reloc;
> + };
> + };
> +};
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On Wed, 2018-07-11 at 08:56 -0500, Jason Rush wrote: > On 7/11/2018 8:48 AM, Marek Vasut wrote: > > On 07/11/2018 03:49 PM, Jason Rush wrote: > > > > > > My mistake. I did disable the dcache after scrubbing too. The > > > code is almost identical to the Arria10 code where after > > > scrubbing it flushes the dcache, then turns it off. > > > > > > The weird reset problems happens if I scrub the area where > > > u-boot relocates to with the dcache on, then turn dcache off. > > > > > > I tried to also tried turning the MMU off, but that didn't help. > > > > Maybe there are some data used by the SPL there ? I think the SPL has > > malloc area in RAM at some point. > > > > I thought something similar, so I narrowed it down to clearing > just from where U-Boot relocates to the end of DRAM. If I'm > correct, that includes where U-Boot relocates and where the > MMU tables are normally stored. I wonder if the reset does not properly reset the CPU caches? The idea being that the CPU cache has stale data from before the reset, or maybe just stale tag bits, and the hang is due to using this bad data from the cache. Or perhaps there is always something done incorrectly, but it is only the state of DRAM after a reset, vs a power cycle, that consistently triggers a hang? If possible, try to add code before the hang point to invalidate both the i-cache and d-cache for the problem region above. Perhaps the SPL is doing something wrong w.r.t. cache invalidation, e.g. moving code around and not updating the i-cache, because it assumes nothing has yet used the caches, which is now no longer the case since you turn them on for scrubbing. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
Since commit f2faffecb016, tegra: Convert to use binman
the dm-pre-reloc properties are removed.
This leads uboot not to enable the display on paz00
This patch restore the dm-pre-reloc properties allowing
the bootloader to output to the display panel
v3: - Fix few typos
v2: - Add more characters to commit hash
Signed-off-by: Nicolas Chauvet
Reviewed-by: Simon Glass
---
arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/tegra20-u-boot.dtsi b/arch/arm/dts/tegra20-u-boot.dtsi
index 7c11972552..f64667e549 100644
--- a/arch/arm/dts/tegra20-u-boot.dtsi
+++ b/arch/arm/dts/tegra20-u-boot.dtsi
@@ -1,3 +1,13 @@
#include
#include "tegra-u-boot.dtsi"
+
+
+/ {
+ host1x@5000 {
+ u-boot,dm-pre-reloc;
+ dc@5420 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
On 11 July 2018 at 09:19, Nicolas Chauvet wrote:
> Since commit f2faffecbd, tegra: Convert to use binman
> the dm-pre-reloc properties are removed.
>
> This lead uboot not to enable the display on paz00
This leads U-Boot ...
>
> This patch restore the dm-pre-reloc properties allowing
> the bootloader to output to the display panel
>
> Signed-off-by: Nicolas Chauvet
> ---
> arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
Reviewed-by: Simon Glass
>
> diff --git a/arch/arm/dts/tegra20-u-boot.dtsi
> b/arch/arm/dts/tegra20-u-boot.dtsi
> index 7c11972552..f64667e549 100644
> --- a/arch/arm/dts/tegra20-u-boot.dtsi
> +++ b/arch/arm/dts/tegra20-u-boot.dtsi
> @@ -1,3 +1,13 @@
> #include
>
> #include "tegra-u-boot.dtsi"
> +
> +
> +/ {
> + host1x@5000 {
> + u-boot,dm-pre-reloc;
> + dc@5420 {
> + u-boot,dm-pre-reloc;
> + };
> + };
> +};
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
Since commit f2faffecb016, tegra: Convert to use binman
the dm-pre-reloc properties are removed.
This lead uboot not to enable the display on paz00
This patch restore the dm-pre-reloc properties allowing
the bootloader to output to the display panel
v2: - Add more character to commit hash
Signed-off-by: Nicolas Chauvet
---
arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/tegra20-u-boot.dtsi b/arch/arm/dts/tegra20-u-boot.dtsi
index 7c11972552..f64667e549 100644
--- a/arch/arm/dts/tegra20-u-boot.dtsi
+++ b/arch/arm/dts/tegra20-u-boot.dtsi
@@ -1,3 +1,13 @@
#include
#include "tegra-u-boot.dtsi"
+
+
+/ {
+ host1x@5000 {
+ u-boot,dm-pre-reloc;
+ dc@5420 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
On 07/11/2018 09:19 AM, Nicolas Chauvet wrote: Since commit f2faffecbd, tegra: Convert to use binman the dm-pre-reloc properties are removed. That commit hash is ambiguous; can we add a few more characters (e.g. "f2faffecb016")? Thanks for tracking this down. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT PULL] u-boot-mips
Hi Tom, Travis CI build: https://travis-ci.org/danielschwierzeck/u-boot/builds/402636234 The following changes since commit e3396ffd720877976141fa0b76a0b8ee9643d7d1: Merge git://git.denx.de/u-boot-dm (2018-07-10 10:29:14 -0400) are available in the Git repository at: git://git.denx.de/u-boot-mips.git master for you to fetch changes up to c38abed5093a486d6349fc0d9d7a663f24965d78: led: bcm6328: read base address in the parent node (2018-07-11 14:23:55 +0200) Daniel Schwierzeck (1): MIPS: add MIPS Release 6 build coverage for Boston boards Philippe Reynes (2): cpu: bmips: fix probe to get the address led: bcm6328: read base address in the parent node configs/boston32r6_defconfig | 41 + configs/boston32r6el_defconfig | 42 ++ configs/boston64r6_defconfig | 41 + configs/boston64r6el_defconfig | 42 ++ drivers/cpu/bmips_cpu.c| 2 +- drivers/led/led_bcm6328.c | 2 +- 6 files changed, 168 insertions(+), 2 deletions(-) create mode 100644 configs/boston32r6_defconfig create mode 100644 configs/boston32r6el_defconfig create mode 100644 configs/boston64r6_defconfig create mode 100644 configs/boston64r6el_defconfig signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 21/21] dt-bindings: Add bindings for SPI NAND devices
From: Boris Brezillon Add bindings for SPI NAND chips. Signed-off-by: Boris Brezillon Signed-off-by: Miquel Raynal --- doc/device-tree-bindings/mtd/spi-nand.txt | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 doc/device-tree-bindings/mtd/spi-nand.txt diff --git a/doc/device-tree-bindings/mtd/spi-nand.txt b/doc/device-tree-bindings/mtd/spi-nand.txt new file mode 100644 index 00..d55f80196c --- /dev/null +++ b/doc/device-tree-bindings/mtd/spi-nand.txt @@ -0,0 +1,27 @@ +SPI NAND flash + +Required properties: +- compatible: should be "spi-nand" +- reg: should encode the chip-select line used to access the NAND chip + +Optional properties +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate at. +This should encode board limitations (i.e. max freq can't +be achieved due to crosstalk on IO lines). +When unspecified, the driver assumes the chip can run at +the max frequency defined in the spec (information +extracted chip detection time). +- spi-tx-bus-width: The bus width (number of data wires) that is used for MOSI. + Only encodes the board constraints (i.e. when not all IO + signals are routed on the board). Device constraints are + extracted when detecting the chip, and controller + constraints are exposed by the SPI mem controller. If this + property is missing that means no constraint at the board + level. +- spi-rx-bus-width: The bus width (number of data wires) that is used for MISO. + Only encodes the board constraints (i.e. when not all IO + signals are routed on the board). Device constraints are + extracted when detecting the chip, and controller + constraints are exposed by the SPI mem controller. If this + property is missing that means no constraint at the board + level. -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 16/21] mtd: spinand: Add initial support for Winbond W25M02GV
From: Frieder Schrempf
Add support for the W25M02GV chip.
Signed-off-by: Frieder Schrempf
Signed-off-by: Boris Brezillon
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/spi/Makefile | 2 +-
drivers/mtd/nand/spi/core.c| 1 +
drivers/mtd/nand/spi/winbond.c | 143 +
include/linux/mtd/spinand.h| 1 +
4 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 drivers/mtd/nand/spi/winbond.c
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 4eb745abd4..11ba5de68b 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-spinand-objs := core.o micron.o
+spinand-objs := core.o micron.o winbond.o
obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 36b8b52bc2..ef3e6445d8 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -831,6 +831,7 @@ static const struct nand_ops spinand_ops = {
static const struct spinand_manufacturer *spinand_manufacturers[] = {
_spinand_manufacturer,
+ _spinand_manufacturer,
};
static int spinand_manufacturer_detect(struct spinand_device *spinand)
diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
new file mode 100644
index 00..eac811d97c
--- /dev/null
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017 exceet electronics GmbH
+ *
+ * Authors:
+ * Frieder Schrempf
+ * Boris Brezillon
+ */
+
+#ifndef __UBOOT__
+#include
+#include
+#endif
+#include
+
+#define SPINAND_MFR_WINBOND0xEF
+
+#define WINBOND_CFG_BUF_READ BIT(3)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+ SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+ SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+ SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+ SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+ SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int w25m02gv_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section > 3)
+ return -ERANGE;
+
+ region->offset = (16 * section) + 8;
+ region->length = 8;
+
+ return 0;
+}
+
+static int w25m02gv_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section > 3)
+ return -ERANGE;
+
+ region->offset = (16 * section) + 2;
+ region->length = 6;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops w25m02gv_ooblayout = {
+ .ecc = w25m02gv_ooblayout_ecc,
+ .free = w25m02gv_ooblayout_free,
+};
+
+static int w25m02gv_select_target(struct spinand_device *spinand,
+ unsigned int target)
+{
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0xc2, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1,
+ spinand->scratchbuf,
+ 1));
+
+ *spinand->scratchbuf = target;
+ return spi_mem_exec_op(spinand->slave, );
+}
+
+static const struct spinand_info winbond_spinand_table[] = {
+ SPINAND_INFO("W25M02GV", 0xAB,
+NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 2),
+NAND_ECCREQ(1, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout, NULL),
+SPINAND_SELECT_TARGET(w25m02gv_select_target)),
+};
+
+/**
+ * winbond_spinand_detect - initialize device related part in spinand_device
+ * struct if it is a Winbond device.
+ * @spinand: SPI NAND device structure
+ */
+static int winbond_spinand_detect(struct spinand_device *spinand)
+{
+ u8 *id = spinand->id.data;
+ int ret;
+
+ /*
+* Winbond SPI NAND read ID need a dummy byte,
+* so the first byte in raw_id is dummy.
+*/
+ if (id[1] != SPINAND_MFR_WINBOND)
+ return 0;
+
+ ret =
[U-Boot] [PATCH v2 20/21] cmd: mtd: add 'mtd' command
There should not be a 'nand' command, a 'sf' command and certainly not
another 'spi-nand'. Write a 'mtd' command instead to manage all MTD
devices at once. This should be the preferred way to access any MTD
device.
Signed-off-by: Miquel Raynal
---
cmd/Kconfig | 5 +
cmd/Makefile | 1 +
cmd/mtd.c| 287 +++
drivers/mtd/Makefile | 2 +-
4 files changed, 294 insertions(+), 1 deletion(-)
create mode 100644 cmd/mtd.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 136836d146..6e9b629e1c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -797,6 +797,11 @@ config CMD_MMC
help
MMC memory mapped support.
+config CMD_MTD
+ bool "mtd"
+ help
+ MTD commands support.
+
config CMD_NAND
bool "nand"
default y if NAND_SUNXI
diff --git a/cmd/Makefile b/cmd/Makefile
index 9a358e4801..e42db12e1d 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_CMD_MISC) += misc.o
obj-$(CONFIG_CMD_MMC) += mmc.o
obj-$(CONFIG_CMD_MMC_SPI) += mmc_spi.o
obj-$(CONFIG_MP) += mp.o
+obj-$(CONFIG_CMD_MTD) += mtd.o
obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
obj-$(CONFIG_CMD_NAND) += nand.o
obj-$(CONFIG_CMD_NET) += net.o
diff --git a/cmd/mtd.c b/cmd/mtd.c
new file mode 100644
index 00..c0809e9ed1
--- /dev/null
+++ b/cmd/mtd.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * mtd.c
+ *
+ * Generic command to handle basic operations on any memory device.
+ *
+ * Copyright: Bootlin, 2018
+ * Author: Miquèl Raynal
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void mtd_dump_buf(u8 *buf, uint len, uint offset)
+{
+ int i, j;
+
+ for (i = 0; i < len; ) {
+ printf("0x%08x:\t", offset + i);
+ for (j = 0; j < 8; j++)
+ printf("%02x ", buf[i + j]);
+ printf(" ");
+ i += 8;
+ for (j = 0; j < 8; j++)
+ printf("%02x ", buf[i + j]);
+ printf("\n");
+ i += 8;
+ }
+}
+
+static void mtd_show_device(struct mtd_info *mtd)
+{
+ printf("* %s", mtd->name);
+ if (mtd->dev)
+ printf(" [device: %s] [parent: %s] [driver: %s]",
+ mtd->dev->name, mtd->dev->parent->name,
+ mtd->dev->driver->name);
+
+ printf("\n");
+}
+
+static void mtd_probe_devices_dm(void)
+{
+ struct udevice *dev;
+ int idx = 0;
+
+ /* Devices with DM compliant drivers */
+ while (!uclass_find_device(UCLASS_MTD, idx, ) && dev) {
+ mtd_probe(dev);
+ idx++;
+ }
+}
+
+static uint mtd_len_to_pages(struct mtd_info *mtd, u64 len)
+{
+ do_div(len, mtd->writesize);
+
+ return len;
+}
+
+static int do_mtd_list(void)
+{
+ struct mtd_info *mtd;
+ int dev_nb = 0;
+
+ /* Ensure all devices are probed */
+ mtd_probe_devices_dm();
+
+ printf("List of MTD devices:\n");
+ mtd_for_each_device(mtd) {
+ mtd_show_device(mtd);
+ dev_nb++;
+ }
+
+ if (!dev_nb) {
+ printf("No MTD device found\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int do_mtd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct mtd_info *mtd;
+ const char *cmd;
+ char *mtdname;
+ int ret;
+
+ /* All MTD commands need at least two arguments */
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ /* Parse the command name and its optional suffixes */
+ cmd = argv[1];
+
+ /* List the MTD devices if that is what the user wants */
+ if (strcmp(cmd, "list") == 0)
+ return do_mtd_list();
+
+ /*
+* The remaining commands require also at least a device ID.
+* Check the selected device is valid. Ensure it is probed.
+*/
+ if (argc < 3)
+ return CMD_RET_USAGE;
+
+ mtdname = argv[2];
+ mtd = get_mtd_device_nm(mtdname);
+ if (IS_ERR_OR_NULL(mtd)) {
+ mtd_probe_devices_dm();
+ mtd = get_mtd_device_nm(mtdname);
+ if (IS_ERR_OR_NULL(mtd)) {
+ printf("MTD device %s not found, ret %ld\n",
+ mtdname, PTR_ERR(mtd));
+ return 1;
+ }
+ }
+
+ argc -= 3;
+ argv += 3;
+
+ /* Do the parsing */
+ if (!strncmp(cmd, "read", 4) || !strncmp(cmd, "dump", 4) ||
+ !strncmp(cmd, "write", 5)) {
+ struct mtd_oob_ops io_op = {};
+ bool dump, read, raw, woob;
+ uint user_addr = 0;
+ uint nb_pages;
+ u8 *buf;
+ u64 off, len;
+ u32 oob_len;
+
+ dump = !strncmp(cmd, "dump", 4);
+
[U-Boot] [PATCH v2 11/21] mtd: nand: Add core infrastructure to deal with NAND devices
From: Boris Brezillon
Add an intermediate layer to abstract NAND device interface so that
some logic can be shared between SPI NANDs, parallel/raw NANDs,
OneNANDs, ...
Signed-off-by: Boris Brezillon
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/Kconfig | 3 +
drivers/mtd/nand/Makefile | 3 +
drivers/mtd/nand/bbt.c| 132 +
drivers/mtd/nand/core.c | 243 +++
include/linux/mtd/nand.h | 731 ++
5 files changed, 1112 insertions(+)
create mode 100644 drivers/mtd/nand/bbt.c
create mode 100644 drivers/mtd/nand/core.c
create mode 100644 include/linux/mtd/nand.h
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 6d53734718..1c1a1f487e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -1 +1,4 @@
+config MTD_NAND_CORE
+ tristate
+
source "drivers/mtd/nand/raw/Kconfig"
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index d1c3f93047..69c80ea252 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -1,3 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
+nandcore-objs := core.o bbt.o
+obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
+
obj-$(CONFIG_MTD_NAND) += raw/
diff --git a/drivers/mtd/nand/bbt.c b/drivers/mtd/nand/bbt.c
new file mode 100644
index 00..7e0ad3190c
--- /dev/null
+++ b/drivers/mtd/nand/bbt.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017 Free Electrons
+ *
+ * Authors:
+ * Boris Brezillon
+ * Peter Pan
+ */
+
+#define pr_fmt(fmt)"nand-bbt: " fmt
+
+#include
+#ifndef __UBOOT__
+#include
+#endif
+
+/**
+ * nanddev_bbt_init() - Initialize the BBT (Bad Block Table)
+ * @nand: NAND device
+ *
+ * Initialize the in-memory BBT.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int nanddev_bbt_init(struct nand_device *nand)
+{
+ unsigned int bits_per_block = fls(NAND_BBT_BLOCK_NUM_STATUS);
+ unsigned int nblocks = nanddev_neraseblocks(nand);
+ unsigned int nwords = DIV_ROUND_UP(nblocks * bits_per_block,
+ BITS_PER_LONG);
+
+ nand->bbt.cache = kzalloc(nwords, GFP_KERNEL);
+ if (!nand->bbt.cache)
+ return -ENOMEM;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_init);
+
+/**
+ * nanddev_bbt_cleanup() - Cleanup the BBT (Bad Block Table)
+ * @nand: NAND device
+ *
+ * Undoes what has been done in nanddev_bbt_init()
+ */
+void nanddev_bbt_cleanup(struct nand_device *nand)
+{
+ kfree(nand->bbt.cache);
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_cleanup);
+
+/**
+ * nanddev_bbt_update() - Update a BBT
+ * @nand: nand device
+ *
+ * Update the BBT. Currently a NOP function since on-flash bbt is not yet
+ * supported.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int nanddev_bbt_update(struct nand_device *nand)
+{
+ return 0;
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_update);
+
+/**
+ * nanddev_bbt_get_block_status() - Return the status of an eraseblock
+ * @nand: nand device
+ * @entry: the BBT entry
+ *
+ * Return: a positive number nand_bbt_block_status status or -%ERANGE if @entry
+ *is bigger than the BBT size.
+ */
+int nanddev_bbt_get_block_status(const struct nand_device *nand,
+unsigned int entry)
+{
+ unsigned int bits_per_block = fls(NAND_BBT_BLOCK_NUM_STATUS);
+ unsigned long *pos = nand->bbt.cache +
+((entry * bits_per_block) / BITS_PER_LONG);
+ unsigned int offs = (entry * bits_per_block) % BITS_PER_LONG;
+ unsigned long status;
+
+ if (entry >= nanddev_neraseblocks(nand))
+ return -ERANGE;
+
+ status = pos[0] >> offs;
+ if (bits_per_block + offs > BITS_PER_LONG)
+ status |= pos[1] << (BITS_PER_LONG - offs);
+
+ return status & GENMASK(bits_per_block - 1, 0);
+}
+EXPORT_SYMBOL_GPL(nanddev_bbt_get_block_status);
+
+/**
+ * nanddev_bbt_set_block_status() - Update the status of an eraseblock in the
+ * in-memory BBT
+ * @nand: nand device
+ * @entry: the BBT entry to update
+ * @status: the new status
+ *
+ * Update an entry of the in-memory BBT. If you want to push the updated BBT
+ * the NAND you should call nanddev_bbt_update().
+ *
+ * Return: 0 in case of success or -%ERANGE if @entry is bigger than the BBT
+ *size.
+ */
+int nanddev_bbt_set_block_status(struct nand_device *nand, unsigned int entry,
+enum nand_bbt_block_status status)
+{
+ unsigned int bits_per_block = fls(NAND_BBT_BLOCK_NUM_STATUS);
+ unsigned long *pos = nand->bbt.cache +
+((entry * bits_per_block) / BITS_PER_LONG);
+ unsigned int offs = (entry * bits_per_block) % BITS_PER_LONG;
+ unsigned long val = status & GENMASK(bits_per_block - 1, 0);
+
+ if (entry >= nanddev_neraseblocks(nand))
+
[U-Boot] [PATCH v2 18/21] mtd: spinand: Add initial support for the MX35LF2GE4AB chip
Add support for the MX35LF2GE4AB chip, which is similar to its cousin
MX35LF1GE4AB, with two planes instead of one.
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/spi/macronix.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
index dd351dcb6c..662c561e50 100644
--- a/drivers/mtd/nand/spi/macronix.c
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -27,13 +27,13 @@ static SPINAND_OP_VARIANTS(update_cache_variants,
SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
SPINAND_PROG_LOAD(false, 0, NULL, 0));
-static int mx35lf1ge4ab_ooblayout_ecc(struct mtd_info *mtd, int section,
+static int mx35lfxge4ab_ooblayout_ecc(struct mtd_info *mtd, int section,
struct mtd_oob_region *region)
{
return -ERANGE;
}
-static int mx35lf1ge4ab_ooblayout_free(struct mtd_info *mtd, int section,
+static int mx35lfxge4ab_ooblayout_free(struct mtd_info *mtd, int section,
struct mtd_oob_region *region)
{
if (section)
@@ -45,9 +45,9 @@ static int mx35lf1ge4ab_ooblayout_free(struct mtd_info *mtd,
int section,
return 0;
}
-static const struct mtd_ooblayout_ops mx35lf1ge4ab_ooblayout = {
- .ecc = mx35lf1ge4ab_ooblayout_ecc,
- .free = mx35lf1ge4ab_ooblayout_free,
+static const struct mtd_ooblayout_ops mx35lfxge4ab_ooblayout = {
+ .ecc = mx35lfxge4ab_ooblayout_ecc,
+ .free = mx35lfxge4ab_ooblayout_free,
};
static int mx35lf1ge4ab_get_eccsr(struct spinand_device *spinand, u8 *eccsr)
@@ -102,8 +102,16 @@ static const struct spinand_info macronix_spinand_table[]
= {
_cache_variants,
_cache_variants),
SPINAND_HAS_QE_BIT,
-SPINAND_ECCINFO(_ooblayout,
+SPINAND_ECCINFO(_ooblayout,
mx35lf1ge4ab_ecc_get_status)),
+ SPINAND_INFO("MX35LF2GE4AB", 0x22,
+NAND_MEMORG(1, 2048, 64, 64, 2048, 2, 1, 1),
+NAND_ECCREQ(4, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+SPINAND_HAS_QE_BIT,
+SPINAND_ECCINFO(_ooblayout, NULL)),
};
static int macronix_spinand_detect(struct spinand_device *spinand)
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 13/21] spi: Extend the core to ease integration of SPI memory controllers
From: Boris Brezillon
Some controllers are exposing high-level interfaces to access various
kind of SPI memories. Unfortunately they do not fit in the current
spi_controller model and usually have drivers placed in
drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI
memories in general.
This is an attempt at defining a SPI memory interface which works for
all kinds of SPI memories (NORs, NANDs, SRAMs).
Signed-off-by: Boris Brezillon
Signed-off-by: Miquel Raynal
---
drivers/spi/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-mem.c | 500 ++
include/spi-mem.h | 258 ++
include/spi.h | 11 ++
5 files changed, 777 insertions(+)
create mode 100644 drivers/spi/spi-mem.c
create mode 100644 include/spi-mem.h
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 235a8c7d73..0ee371b2d9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -15,6 +15,13 @@ config DM_SPI
if DM_SPI
+config SPI_MEM
+ bool "SPI memory extension"
+ help
+ Enable this option if you want to enable the SPI memory extension.
+ This extension is meant to simplify interaction with SPI memories
+ by providing an high-level interface to send memory-like commands.
+
config ALTERA_SPI
bool "Altera SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 4b6000fd9a..982529a0e6 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -10,6 +10,7 @@ ifdef CONFIG_DM_SPI
obj-y += spi-uclass.o
obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
obj-$(CONFIG_SOFT_SPI) += soft_spi.o
+obj-$(CONFIG_SPI_MEM) += spi-mem.o
else
obj-y += spi.o
obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
new file mode 100644
index 00..1aabe56819
--- /dev/null
+++ b/drivers/spi/spi-mem.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Exceet Electronics GmbH
+ * Copyright (C) 2018 Bootlin
+ *
+ * Author: Boris Brezillon
+ */
+
+#ifndef __UBOOT__
+#include
+#include
+#include "internals.h"
+#else
+#include
+#include
+#endif
+
+#ifndef __UBOOT__
+/**
+ * spi_controller_dma_map_mem_op_data() - DMA-map the buffer attached to a
+ * memory operation
+ * @ctlr: the SPI controller requesting this dma_map()
+ * @op: the memory operation containing the buffer to map
+ * @sgt: a pointer to a non-initialized sg_table that will be filled by this
+ * function
+ *
+ * Some controllers might want to do DMA on the data buffer embedded in @op.
+ * This helper prepares everything for you and provides a ready-to-use
+ * sg_table. This function is not intended to be called from spi drivers.
+ * Only SPI controller drivers should use it.
+ * Note that the caller must ensure the memory region pointed by
+ * op->data.buf.{in,out} is DMA-able before calling this function.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
+ const struct spi_mem_op *op,
+ struct sg_table *sgt)
+{
+ struct device *dmadev;
+
+ if (!op->data.nbytes)
+ return -EINVAL;
+
+ if (op->data.dir == SPI_MEM_DATA_OUT && ctlr->dma_tx)
+ dmadev = ctlr->dma_tx->device->dev;
+ else if (op->data.dir == SPI_MEM_DATA_IN && ctlr->dma_rx)
+ dmadev = ctlr->dma_rx->device->dev;
+ else
+ dmadev = ctlr->dev.parent;
+
+ if (!dmadev)
+ return -EINVAL;
+
+ return spi_map_buf(ctlr, dmadev, sgt, op->data.buf.in, op->data.nbytes,
+ op->data.dir == SPI_MEM_DATA_IN ?
+ DMA_FROM_DEVICE : DMA_TO_DEVICE);
+}
+EXPORT_SYMBOL_GPL(spi_controller_dma_map_mem_op_data);
+
+/**
+ * spi_controller_dma_unmap_mem_op_data() - DMA-unmap the buffer attached to a
+ * memory operation
+ * @ctlr: the SPI controller requesting this dma_unmap()
+ * @op: the memory operation containing the buffer to unmap
+ * @sgt: a pointer to an sg_table previously initialized by
+ * spi_controller_dma_map_mem_op_data()
+ *
+ * Some controllers might want to do DMA on the data buffer embedded in @op.
+ * This helper prepares things so that the CPU can access the
+ * op->data.buf.{in,out} buffer again.
+ *
+ * This function is not intended to be called from SPI drivers. Only SPI
+ * controller drivers should use it.
+ *
+ * This function should be called after the DMA operation has finished and is
+ * only valid if the previous spi_controller_dma_map_mem_op_data() call
+ * returned 0.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
+
[U-Boot] [PATCH] arm: tegra: Restore host1x/dc dm-pre-reloc properties
Since commit f2faffecbd, tegra: Convert to use binman
the dm-pre-reloc properties are removed.
This lead uboot not to enable the display on paz00
This patch restore the dm-pre-reloc properties allowing
the bootloader to output to the display panel
Signed-off-by: Nicolas Chauvet
---
arch/arm/dts/tegra20-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/tegra20-u-boot.dtsi b/arch/arm/dts/tegra20-u-boot.dtsi
index 7c11972552..f64667e549 100644
--- a/arch/arm/dts/tegra20-u-boot.dtsi
+++ b/arch/arm/dts/tegra20-u-boot.dtsi
@@ -1,3 +1,13 @@
#include
#include "tegra-u-boot.dtsi"
+
+
+/ {
+ host1x@5000 {
+ u-boot,dm-pre-reloc;
+ dc@5420 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 14/21] mtd: nand: Add core infrastructure to support SPI NANDs
From: Peter Pan
Add a SPI NAND framework based on the generic NAND framework and the
spi-mem infrastructure.
In its current state, this framework supports the following features:
- single/dual/quad IO modes
- on-die ECC
Signed-off-by: Peter Pan
Signed-off-by: Boris Brezillon
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/Kconfig |2 +
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/spi/Kconfig |7 +
drivers/mtd/nand/spi/Makefile |4 +
drivers/mtd/nand/spi/core.c | 1235 +
include/linux/mtd/spinand.h | 427 ++
6 files changed, 1676 insertions(+)
create mode 100644 drivers/mtd/nand/spi/Kconfig
create mode 100644 drivers/mtd/nand/spi/Makefile
create mode 100644 drivers/mtd/nand/spi/core.c
create mode 100644 include/linux/mtd/spinand.h
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 1c1a1f487e..78ae04bdcb 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -2,3 +2,5 @@ config MTD_NAND_CORE
tristate
source "drivers/mtd/nand/raw/Kconfig"
+
+source "drivers/mtd/nand/spi/Kconfig"
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 69c80ea252..cbac19b38a 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -4,3 +4,4 @@ nandcore-objs := core.o bbt.o
obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
obj-$(CONFIG_MTD_NAND) += raw/
+obj-$(CONFIG_MTD_SPI_NAND) += spi/
diff --git a/drivers/mtd/nand/spi/Kconfig b/drivers/mtd/nand/spi/Kconfig
new file mode 100644
index 00..2197cb531f
--- /dev/null
+++ b/drivers/mtd/nand/spi/Kconfig
@@ -0,0 +1,7 @@
+menuconfig MTD_SPI_NAND
+ bool "SPI NAND device Support"
+ depends on MTD && DM_SPI
+ select MTD_NAND_CORE
+ select SPI_MEM
+ help
+ This is the framework for the SPI NAND device drivers.
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
new file mode 100644
index 00..f0c6e69d2e
--- /dev/null
+++ b/drivers/mtd/nand/spi/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+spinand-objs := core.o
+obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
new file mode 100644
index 00..08f853ae11
--- /dev/null
+++ b/drivers/mtd/nand/spi/core.c
@@ -0,0 +1,1235 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2017 Micron Technology, Inc.
+ *
+ * Authors:
+ * Peter Pan
+ * Boris Brezillon
+ */
+
+#define pr_fmt(fmt)"spi-nand: " fmt
+
+#ifndef __UBOOT__
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#else
+#include
+#include
+#include
+#include
+#include
+#endif
+
+/* SPI NAND index visible in MTD names */
+static int spi_nand_idx;
+
+static void spinand_cache_op_adjust_colum(struct spinand_device *spinand,
+ const struct nand_page_io_req *req,
+ u16 *column)
+{
+ struct nand_device *nand = spinand_to_nand(spinand);
+ unsigned int shift;
+
+ if (nand->memorg.planes_per_lun < 2)
+ return;
+
+ /* The plane number is passed in MSB just above the column address */
+ shift = fls(nand->memorg.pagesize);
+ *column |= req->pos.plane << shift;
+}
+
+static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val)
+{
+ struct spi_mem_op op = SPINAND_GET_FEATURE_OP(reg,
+ spinand->scratchbuf);
+ int ret;
+
+ ret = spi_mem_exec_op(spinand->slave, );
+ if (ret)
+ return ret;
+
+ *val = *spinand->scratchbuf;
+ return 0;
+}
+
+static int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
+{
+ struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg,
+ spinand->scratchbuf);
+
+ *spinand->scratchbuf = val;
+ return spi_mem_exec_op(spinand->slave, );
+}
+
+static int spinand_read_status(struct spinand_device *spinand, u8 *status)
+{
+ return spinand_read_reg_op(spinand, REG_STATUS, status);
+}
+
+static int spinand_get_cfg(struct spinand_device *spinand, u8 *cfg)
+{
+ struct nand_device *nand = spinand_to_nand(spinand);
+
+ if (WARN_ON(spinand->cur_target < 0 ||
+ spinand->cur_target >= nand->memorg.ntargets))
+ return -EINVAL;
+
+ *cfg = spinand->cfg_cache[spinand->cur_target];
+ return 0;
+}
+
+static int spinand_set_cfg(struct spinand_device *spinand, u8 cfg)
+{
+ struct nand_device *nand = spinand_to_nand(spinand);
+ int ret;
+
+ if (WARN_ON(spinand->cur_target < 0 ||
+ spinand->cur_target >= nand->memorg.ntargets))
+ return -EINVAL;
+
+ if (spinand->cfg_cache[spinand->cur_target] == cfg)
+ return 0;
+
+ ret =
[U-Boot] [PATCH v2 17/21] mtd: spinand: Add initial support for the MX35LF1GE4AB chip
From: Boris Brezillon
Add minimal support for the MX35LF1GE4AB SPI NAND chip.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/spi/Makefile | 2 +-
drivers/mtd/nand/spi/core.c | 1 +
drivers/mtd/nand/spi/macronix.c | 138
include/linux/mtd/spinand.h | 1 +
4 files changed, 141 insertions(+), 1 deletion(-)
create mode 100644 drivers/mtd/nand/spi/macronix.c
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 11ba5de68b..a66edd9199 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-spinand-objs := core.o micron.o winbond.o
+spinand-objs := core.o macronix.o micron.o winbond.o
obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index ef3e6445d8..362d104846 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -830,6 +830,7 @@ static const struct nand_ops spinand_ops = {
};
static const struct spinand_manufacturer *spinand_manufacturers[] = {
+ _spinand_manufacturer,
_spinand_manufacturer,
_spinand_manufacturer,
};
diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
new file mode 100644
index 00..dd351dcb6c
--- /dev/null
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 Macronix
+ *
+ * Author: Boris Brezillon
+ */
+
+#ifndef __UBOOT__
+#include
+#include
+#endif
+#include
+
+#define SPINAND_MFR_MACRONIX 0xC2
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+ SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+ SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+ SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+ SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+ SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int mx35lf1ge4ab_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ return -ERANGE;
+}
+
+static int mx35lf1ge4ab_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = 2;
+ region->length = mtd->oobsize - 2;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops mx35lf1ge4ab_ooblayout = {
+ .ecc = mx35lf1ge4ab_ooblayout_ecc,
+ .free = mx35lf1ge4ab_ooblayout_free,
+};
+
+static int mx35lf1ge4ab_get_eccsr(struct spinand_device *spinand, u8 *eccsr)
+{
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x7c, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_DUMMY(1, 1),
+ SPI_MEM_OP_DATA_IN(1, eccsr, 1));
+
+ return spi_mem_exec_op(spinand->slave, );
+}
+
+static int mx35lf1ge4ab_ecc_get_status(struct spinand_device *spinand,
+ u8 status)
+{
+ struct nand_device *nand = spinand_to_nand(spinand);
+ u8 eccsr;
+
+ switch (status & STATUS_ECC_MASK) {
+ case STATUS_ECC_NO_BITFLIPS:
+ return 0;
+
+ case STATUS_ECC_UNCOR_ERROR:
+ return -EBADMSG;
+
+ case STATUS_ECC_HAS_BITFLIPS:
+ /*
+* Let's try to retrieve the real maximum number of bitflips
+* in order to avoid forcing the wear-leveling layer to move
+* data around if it's not necessary.
+*/
+ if (mx35lf1ge4ab_get_eccsr(spinand, ))
+ return nand->eccreq.strength;
+
+ if (WARN_ON(eccsr > nand->eccreq.strength || !eccsr))
+ return nand->eccreq.strength;
+
+ return eccsr;
+
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static const struct spinand_info macronix_spinand_table[] = {
+ SPINAND_INFO("MX35LF1GE4AB", 0x12,
+NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 1),
+NAND_ECCREQ(4, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+SPINAND_HAS_QE_BIT,
+SPINAND_ECCINFO(_ooblayout,
+mx35lf1ge4ab_ecc_get_status)),
+};
+
+static int macronix_spinand_detect(struct spinand_device *spinand)
+{
+
[U-Boot] [PATCH v2 06/21] mtd: fix build issue with includes
Fix build errors produced by mtd.h and dm/device.h if not included in the right order. Signed-off-by: Miquel Raynal Reviewed-by: Jagan Teki --- include/linux/mtd/mtd.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 5b110ec873..8ffc33b0cc 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -22,6 +22,7 @@ #include #include #include +#include #define MAX_MTD_DEVICES 32 #endif -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/21] mtd: add get/set of_node/flash_node helpers
From: Brian Norris
We are going to begin using the mtd->dev.of_node field for MTD device
nodes, so let's add helpers for it. Also, we'll be making some
conversions on spi_nor (and nand_chip eventually) too, so get that ready
with their own helpers.
Signed-off-by: Brian Norris
Reviewed-by: Boris Brezillon
Signed-off-by: Miquel Raynal
Reviewed-by: Jagan Teki
---
include/linux/mtd/mtd.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 13455e0d24..5b110ec873 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -311,6 +311,17 @@ struct mtd_info {
int usecount;
};
+static inline void mtd_set_of_node(struct mtd_info *mtd,
+ const struct device_node *np)
+{
+ mtd->dev->node.np = np;
+}
+
+static inline const struct device_node *mtd_get_of_node(struct mtd_info *mtd)
+{
+ return mtd->dev->node.np;
+}
+
int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobecc);
int mtd_ooblayout_find_eccregion(struct mtd_info *mtd, int eccbyte,
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 19/21] mtd: uclass: add probe function
The user might want to trigger the probe of any MTD device, export these
functions so they can be called from a command source file.
Signed-off-by: Miquel Raynal
---
drivers/mtd/mtd-uclass.c | 9 +
include/linux/mtd/mtd.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/mtd/mtd-uclass.c b/drivers/mtd/mtd-uclass.c
index 7b7c48ec5a..1b6533829c 100644
--- a/drivers/mtd/mtd-uclass.c
+++ b/drivers/mtd/mtd-uclass.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
@@ -14,6 +15,14 @@
* The uclass private is pointed to mtd_info.
*/
+int mtd_probe(struct udevice *dev)
+{
+ if (device_active(dev))
+ return 0;
+
+ return device_probe(dev);
+}
+
UCLASS_DRIVER(mtd) = {
.id = UCLASS_MTD,
.name = "mtd",
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 9a63bf4a49..7dfcaadf50 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -538,5 +538,8 @@ int mtd_arg_off_size(int argc, char *const argv[], int
*idx, loff_t *off,
void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t offset,
const uint64_t length, uint64_t *len_incl_bad,
int *truncated);
+
+int mtd_probe(struct udevice *dev);
+
#endif
#endif /* __MTD_MTD_H__ */
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 10/21] mtd: rename nand into rawnand in Kconfig prompt
Sync the Kconfig raw NAND entry title with the code architecture. Signed-off-by: Miquel Raynal --- drivers/mtd/nand/raw/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a820af61ce..6ef82cab88 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -1,6 +1,6 @@ menuconfig NAND - bool "NAND Device Support" + bool "Raw NAND Device Support" if NAND config SYS_NAND_SELF_INIT -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 15/21] mtd: spinand: Add initial support for Micron MT29F2G01ABAGD
From: Peter Pan
Add a basic driver for Micron SPI NANDs. Only one device is supported
right now, but the driver will be extended to support more devices
afterwards.
Signed-off-by: Peter Pan
Signed-off-by: Boris Brezillon
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/spi/Makefile | 2 +-
drivers/mtd/nand/spi/core.c | 17 ++
drivers/mtd/nand/spi/micron.c | 135 ++
include/linux/mtd/spinand.h | 3 +
4 files changed, 156 insertions(+), 1 deletion(-)
create mode 100644 drivers/mtd/nand/spi/micron.c
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index f0c6e69d2e..4eb745abd4 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-spinand-objs := core.o
+spinand-objs := core.o micron.o
obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 08f853ae11..36b8b52bc2 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -829,8 +829,25 @@ static const struct nand_ops spinand_ops = {
.isbad = spinand_isbad,
};
+static const struct spinand_manufacturer *spinand_manufacturers[] = {
+ _spinand_manufacturer,
+};
+
static int spinand_manufacturer_detect(struct spinand_device *spinand)
{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(spinand_manufacturers); i++) {
+ ret = spinand_manufacturers[i]->ops->detect(spinand);
+ if (ret > 0) {
+ spinand->manufacturer = spinand_manufacturers[i];
+ return 0;
+ } else if (ret < 0) {
+ return ret;
+ }
+ }
+
return -ENOTSUPP;
}
diff --git a/drivers/mtd/nand/spi/micron.c b/drivers/mtd/nand/spi/micron.c
new file mode 100644
index 00..83951c5d0f
--- /dev/null
+++ b/drivers/mtd/nand/spi/micron.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2016-2017 Micron Technology, Inc.
+ *
+ * Authors:
+ * Peter Pan
+ */
+
+#ifndef __UBOOT__
+#include
+#include
+#endif
+#include
+
+#define SPINAND_MFR_MICRON 0x2c
+
+#define MICRON_STATUS_ECC_MASK GENMASK(7, 4)
+#define MICRON_STATUS_ECC_NO_BITFLIPS (0 << 4)
+#define MICRON_STATUS_ECC_1TO3_BITFLIPS(1 << 4)
+#define MICRON_STATUS_ECC_4TO6_BITFLIPS(3 << 4)
+#define MICRON_STATUS_ECC_7TO8_BITFLIPS(5 << 4)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+ SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+ SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+ SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+ SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+ SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int mt29f2g01abagd_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = 64;
+ region->length = 64;
+
+ return 0;
+}
+
+static int mt29f2g01abagd_ooblayout_free(struct mtd_info *mtd, int section,
+struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ /* Reserve 2 bytes for the BBM. */
+ region->offset = 2;
+ region->length = 62;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops mt29f2g01abagd_ooblayout = {
+ .ecc = mt29f2g01abagd_ooblayout_ecc,
+ .free = mt29f2g01abagd_ooblayout_free,
+};
+
+static int mt29f2g01abagd_ecc_get_status(struct spinand_device *spinand,
+u8 status)
+{
+ switch (status & MICRON_STATUS_ECC_MASK) {
+ case STATUS_ECC_NO_BITFLIPS:
+ return 0;
+
+ case STATUS_ECC_UNCOR_ERROR:
+ return -EBADMSG;
+
+ case MICRON_STATUS_ECC_1TO3_BITFLIPS:
+ return 3;
+
+ case MICRON_STATUS_ECC_4TO6_BITFLIPS:
+ return 6;
+
+ case MICRON_STATUS_ECC_7TO8_BITFLIPS:
+ return 8;
+
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static const struct spinand_info micron_spinand_table[] = {
+ SPINAND_INFO("MT29F2G01ABAGD", 0x24,
+NAND_MEMORG(1, 2048, 128, 64, 2048, 2, 1, 1),
+NAND_ECCREQ(8, 512),
+
[U-Boot] [PATCH v2 07/21] mtd: move definitions to enlarge their range
Some helpers might be useful in a future 'mtd' U-Boot command to parse MTD device list. Signed-off-by: Miquel Raynal --- drivers/mtd/mtdcore.h | 6 -- include/linux/mtd/mtd.h | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/mtdcore.h b/drivers/mtd/mtdcore.h index 7b0353399a..1d181a1045 100644 --- a/drivers/mtd/mtdcore.h +++ b/drivers/mtd/mtdcore.h @@ -5,7 +5,6 @@ extern struct mutex mtd_table_mutex; -struct mtd_info *__mtd_next_device(int i); int add_mtd_device(struct mtd_info *mtd); int del_mtd_device(struct mtd_info *mtd); int add_mtd_partitions(struct mtd_info *, const struct mtd_partition *, int); @@ -16,8 +15,3 @@ int parse_mtd_partitions(struct mtd_info *master, const char * const *types, int __init init_mtdchar(void); void __exit cleanup_mtdchar(void); - -#define mtd_for_each_device(mtd) \ - for ((mtd) = __mtd_next_device(0); \ -(mtd) != NULL; \ -(mtd) = __mtd_next_device(mtd->index + 1)) diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 8ffc33b0cc..9a63bf4a49 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -522,6 +522,12 @@ int del_mtd_device(struct mtd_info *mtd); int add_mtd_partitions(struct mtd_info *, const struct mtd_partition *, int); int del_mtd_partitions(struct mtd_info *); +struct mtd_info *__mtd_next_device(int i); +#define mtd_for_each_device(mtd) \ + for ((mtd) = __mtd_next_device(0); \ +(mtd) != NULL; \ +(mtd) = __mtd_next_device(mtd->index + 1)) + int mtd_arg_off(const char *arg, int *idx, loff_t *off, loff_t *size, loff_t *maxsize, int devtype, uint64_t chipsize); int mtd_arg_off_size(int argc, char *const argv[], int *idx, loff_t *off, -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/21] mtd: move NAND fiels into a raw/ subdirectory
NAND flavors, like serial and parallel, have a lot in common and would
benefit to share code. Let's move raw (parallel) NAND specific code in a
raw/ subdirectory, to ease the addition of a core file in nand/ and the
introduction of a spi/ subdirectory specific to SPI NANDs.
Signed-off-by: Miquel Raynal
---
drivers/mtd/Makefile | 2 +
drivers/mtd/nand/Kconfig | 240 +-
drivers/mtd/nand/Makefile | 79 +
drivers/mtd/nand/raw/Kconfig | 239 +
drivers/mtd/nand/raw/Makefile | 78 +
drivers/mtd/nand/{ => raw}/am335x_spl_bch.c | 0
drivers/mtd/nand/{ => raw}/arasan_nfc.c | 0
drivers/mtd/nand/{ => raw}/atmel_nand.c | 0
drivers/mtd/nand/{ => raw}/atmel_nand_ecc.h | 0
drivers/mtd/nand/{ => raw}/davinci_nand.c | 0
drivers/mtd/nand/{ => raw}/denali.c | 0
drivers/mtd/nand/{ => raw}/denali.h | 0
drivers/mtd/nand/{ => raw}/denali_dt.c| 0
drivers/mtd/nand/{ => raw}/denali_spl.c | 0
drivers/mtd/nand/{ => raw}/fsl_elbc_nand.c| 0
drivers/mtd/nand/{ => raw}/fsl_elbc_spl.c | 0
drivers/mtd/nand/{ => raw}/fsl_ifc_nand.c | 0
drivers/mtd/nand/{ => raw}/fsl_ifc_spl.c | 0
drivers/mtd/nand/{ => raw}/fsl_upm.c | 0
drivers/mtd/nand/{ => raw}/fsmc_nand.c| 0
drivers/mtd/nand/{ => raw}/kb9202_nand.c | 0
drivers/mtd/nand/{ => raw}/kirkwood_nand.c| 0
drivers/mtd/nand/{ => raw}/kmeter1_nand.c | 0
drivers/mtd/nand/{ => raw}/lpc32xx_nand_mlc.c | 0
drivers/mtd/nand/{ => raw}/lpc32xx_nand_slc.c | 0
drivers/mtd/nand/{ => raw}/mxc_nand.c | 0
drivers/mtd/nand/{ => raw}/mxc_nand.h | 0
drivers/mtd/nand/{ => raw}/mxc_nand_spl.c | 0
drivers/mtd/nand/{ => raw}/mxs_nand.c | 0
drivers/mtd/nand/{ => raw}/mxs_nand_spl.c | 0
drivers/mtd/nand/{ => raw}/nand.c | 0
drivers/mtd/nand/{ => raw}/nand_base.c| 0
drivers/mtd/nand/{ => raw}/nand_bbt.c | 0
drivers/mtd/nand/{ => raw}/nand_bch.c | 0
drivers/mtd/nand/{ => raw}/nand_ecc.c | 0
drivers/mtd/nand/{ => raw}/nand_ids.c | 0
drivers/mtd/nand/{ => raw}/nand_plat.c| 0
drivers/mtd/nand/{ => raw}/nand_spl_load.c| 0
drivers/mtd/nand/{ => raw}/nand_spl_loaders.c | 0
drivers/mtd/nand/{ => raw}/nand_spl_simple.c | 0
drivers/mtd/nand/{ => raw}/nand_timings.c | 0
drivers/mtd/nand/{ => raw}/nand_util.c| 0
drivers/mtd/nand/{ => raw}/ndfc.c | 0
drivers/mtd/nand/{ => raw}/omap_elm.c | 0
drivers/mtd/nand/{ => raw}/omap_gpmc.c| 0
drivers/mtd/nand/{ => raw}/pxa3xx_nand.c | 0
drivers/mtd/nand/{ => raw}/pxa3xx_nand.h | 0
drivers/mtd/nand/{ => raw}/sunxi_nand.c | 0
drivers/mtd/nand/{ => raw}/sunxi_nand_spl.c | 0
drivers/mtd/nand/{ => raw}/tegra_nand.c | 0
drivers/mtd/nand/{ => raw}/tegra_nand.h | 0
drivers/mtd/nand/{ => raw}/vf610_nfc.c| 0
drivers/mtd/nand/{ => raw}/zynq_nand.c| 0
53 files changed, 322 insertions(+), 316 deletions(-)
create mode 100644 drivers/mtd/nand/raw/Kconfig
create mode 100644 drivers/mtd/nand/raw/Makefile
rename drivers/mtd/nand/{ => raw}/am335x_spl_bch.c (100%)
rename drivers/mtd/nand/{ => raw}/arasan_nfc.c (100%)
rename drivers/mtd/nand/{ => raw}/atmel_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/atmel_nand_ecc.h (100%)
rename drivers/mtd/nand/{ => raw}/davinci_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/denali.c (100%)
rename drivers/mtd/nand/{ => raw}/denali.h (100%)
rename drivers/mtd/nand/{ => raw}/denali_dt.c (100%)
rename drivers/mtd/nand/{ => raw}/denali_spl.c (100%)
rename drivers/mtd/nand/{ => raw}/fsl_elbc_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/fsl_elbc_spl.c (100%)
rename drivers/mtd/nand/{ => raw}/fsl_ifc_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/fsl_ifc_spl.c (100%)
rename drivers/mtd/nand/{ => raw}/fsl_upm.c (100%)
rename drivers/mtd/nand/{ => raw}/fsmc_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/kb9202_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/kirkwood_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/kmeter1_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/lpc32xx_nand_mlc.c (100%)
rename drivers/mtd/nand/{ => raw}/lpc32xx_nand_slc.c (100%)
rename drivers/mtd/nand/{ => raw}/mxc_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/mxc_nand.h (100%)
rename drivers/mtd/nand/{ => raw}/mxc_nand_spl.c (100%)
rename drivers/mtd/nand/{ => raw}/mxs_nand.c (100%)
rename drivers/mtd/nand/{ => raw}/mxs_nand_spl.c (100%)
rename drivers/mtd/nand/{ => raw}/nand.c (100%)
rename drivers/mtd/nand/{ => raw}/nand_base.c (100%)
rename drivers/mtd/nand/{ => raw}/nand_bbt.c (100%)
rename drivers/mtd/nand/{ => raw}/nand_bch.c (100%)
rename drivers/mtd/nand/{ => raw}/nand_ecc.c
[U-Boot] [PATCH v2 12/21] mtd: nand: Pass mode information to nand_page_io_req
From: Boris Brezillon
The NAND sub-layers are likely to need the MTD_OPS_XXX mode information
in order to decide if they should enable/disable ECC or how they should
place the OOB bytes in the provided OOB buffer.
Add a field to nand_page_io_req to pass this information.
Signed-off-by: Boris Brezillon
Signed-off-by: Miquel Raynal
---
include/linux/mtd/nand.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index ada7af4a41..13e8dd1103 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -86,6 +86,7 @@ struct nand_pos {
* @ooboffs: the OOB offset within the page
* @ooblen: the number of OOB bytes to read from/write to this page
* @oobbuf: buffer to store OOB data in or get OOB data from
+ * @mode: one of the %MTD_OPS_XXX mode
*
* This object is used to pass per-page I/O requests to NAND sub-layers. This
* way all useful information are already formatted in a useful way and
@@ -106,6 +107,7 @@ struct nand_page_io_req {
const void *out;
void *in;
} oobbuf;
+ int mode;
};
/**
@@ -599,6 +601,7 @@ static inline void nanddev_io_iter_init(struct nand_device
*nand,
{
struct mtd_info *mtd = nanddev_to_mtd(nand);
+ iter->req.mode = req->mode;
iter->req.dataoffs = nanddev_offs_to_pos(nand, offs, >req.pos);
iter->req.ooboffs = req->ooboffs;
iter->oobbytes_per_page = mtd_oobavail(mtd, req);
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/21] mtd: Add sanity checks in mtd_write/read_oob()
From: Boris Brezillon
Unlike what's done in mtd_read/write(), there are no checks to make sure
the parameters passed to mtd_read/write_oob() are consistent, which
forces implementers of ->_read/write_oob() to do it, which in turn leads
to code duplication and possibly errors in the logic.
Do general sanity checks, like ops fields consistency and range checking.
Signed-off-by: Boris Brezillon
Cc: Peter Pan
Signed-off-by: Richard Weinberger
[Miquel: squashed the fix about the chip's size check]
Signed-off-by: Miquel Raynal
---
drivers/mtd/mtdcore.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index c22ca20368..ba170f212e 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1011,12 +1011,50 @@ int mtd_panic_write(struct mtd_info *mtd, loff_t to,
size_t len, size_t *retlen,
}
EXPORT_SYMBOL_GPL(mtd_panic_write);
+static int mtd_check_oob_ops(struct mtd_info *mtd, loff_t offs,
+struct mtd_oob_ops *ops)
+{
+ /*
+* Some users are setting ->datbuf or ->oobbuf to NULL, but are leaving
+* ->len or ->ooblen uninitialized. Force ->len and ->ooblen to 0 in
+* this case.
+*/
+ if (!ops->datbuf)
+ ops->len = 0;
+
+ if (!ops->oobbuf)
+ ops->ooblen = 0;
+
+ if (offs < 0 || offs + ops->len > mtd->size)
+ return -EINVAL;
+
+ if (ops->ooblen) {
+ u64 maxooblen;
+
+ if (ops->ooboffs >= mtd_oobavail(mtd, ops))
+ return -EINVAL;
+
+ maxooblen = ((mtd_div_by_ws(mtd->size, mtd) -
+ mtd_div_by_ws(offs, mtd)) *
+mtd_oobavail(mtd, ops)) - ops->ooboffs;
+ if (ops->ooblen > maxooblen)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
{
int ret_code;
ops->retlen = ops->oobretlen = 0;
if (!mtd->_read_oob)
return -EOPNOTSUPP;
+
+ ret_code = mtd_check_oob_ops(mtd, from, ops);
+ if (ret_code)
+ return ret_code;
+
/*
* In cases where ops->datbuf != NULL, mtd->_read_oob() has semantics
* similar to mtd->_read(), returning a non-negative integer
@@ -1035,11 +1073,18 @@ EXPORT_SYMBOL_GPL(mtd_read_oob);
int mtd_write_oob(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops)
{
+ int ret;
+
ops->retlen = ops->oobretlen = 0;
if (!mtd->_write_oob)
return -EOPNOTSUPP;
if (!(mtd->flags & MTD_WRITEABLE))
return -EROFS;
+
+ ret = mtd_check_oob_ops(mtd, to, ops);
+ if (ret)
+ return ret;
+
return mtd->_write_oob(mtd, to, ops);
}
EXPORT_SYMBOL_GPL(mtd_write_oob);
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/21] mtd: move all flash categories inside MTD submenu
There is no reason to have NAND, SPI flashes and UBI sections outside of the MTD submenu in Kconfig. Signed-off-by: Miquel Raynal Reviewed-by: Jagan Teki --- drivers/mtd/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 19579801d2..d21b0920dc 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -40,10 +40,10 @@ config FLASH_PIC32 This enables access to Microchip PIC32 internal non-CFI flash chips through PIC32 Non-Volatile-Memory Controller. -endmenu - source "drivers/mtd/nand/Kconfig" source "drivers/mtd/spi/Kconfig" source "drivers/mtd/ubi/Kconfig" + +endmenu -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 02/21] mtd: Uninline mtd_write_oob and move it to mtdcore.c
From: Ezequiel Garcia
There's no reason for having mtd_write_oob inlined in mtd.h header.
Move it to mtdcore.c where it belongs.
Signed-off-by: Ezequiel Garcia
Acked-by: Boris Brezillon
Signed-off-by: Jacek Anaszewski
Signed-off-by: Miquel Raynal
---
drivers/mtd/mtdcore.c | 12
include/linux/mtd/mtd.h | 12 +---
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 15e0ac2f3e..c22ca20368 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1032,6 +1032,18 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
}
EXPORT_SYMBOL_GPL(mtd_read_oob);
+int mtd_write_oob(struct mtd_info *mtd, loff_t to,
+ struct mtd_oob_ops *ops)
+{
+ ops->retlen = ops->oobretlen = 0;
+ if (!mtd->_write_oob)
+ return -EOPNOTSUPP;
+ if (!(mtd->flags & MTD_WRITEABLE))
+ return -EROFS;
+ return mtd->_write_oob(mtd, to, ops);
+}
+EXPORT_SYMBOL_GPL(mtd_write_oob);
+
/**
* mtd_ooblayout_ecc - Get the OOB region definition of a specific ECC section
* @mtd: MTD device structure
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index ba4cbba949..13455e0d24 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -356,17 +356,7 @@ int mtd_panic_write(struct mtd_info *mtd, loff_t to,
size_t len, size_t *retlen,
const u_char *buf);
int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops);
-
-static inline int mtd_write_oob(struct mtd_info *mtd, loff_t to,
- struct mtd_oob_ops *ops)
-{
- ops->retlen = ops->oobretlen = 0;
- if (!mtd->_write_oob)
- return -EOPNOTSUPP;
- if (!(mtd->flags & MTD_WRITEABLE))
- return -EROFS;
- return mtd->_write_oob(mtd, to, ops);
-}
+int mtd_write_oob(struct mtd_info *mtd, loff_t to, struct mtd_oob_ops *ops);
int mtd_get_fact_prot_info(struct mtd_info *mtd, size_t len, size_t *retlen,
struct otp_info *buf);
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 04/21] mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing
Some MTD sublayers/drivers are implementing ->_read/write() and
not ->_read/write_oob().
While for NAND devices both are usually valid, for NOR devices, using
the _oob variant has no real meaning. But, as the MTD layer is supposed
to hide as much as possible the flash complexity to the user, there is
no reason to error out while it is just a matter of rewritting things
internally.
Add a fallback on mtd->_read() (resp. mtd->_write()) when the user calls
mtd_read_oob() (resp. mtd_write_oob()) while mtd->_read_oob() (resp.
mtd->_write_oob) is not implemented. There is already a fallback on the
_oob variant if the former is used.
Signed-off-by: Miquel Raynal
---
drivers/mtd/mtdcore.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index ba170f212e..095c58cf8c 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1048,20 +1048,27 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
int ret_code;
ops->retlen = ops->oobretlen = 0;
- if (!mtd->_read_oob)
- return -EOPNOTSUPP;
ret_code = mtd_check_oob_ops(mtd, from, ops);
if (ret_code)
return ret_code;
+ /* Check the validity of a potential fallback on mtd->_read */
+ if ((!mtd->_read_oob) && (!mtd->_read || ops->oobbuf))
+ return -EOPNOTSUPP;
+
+ if (mtd->_read_oob)
+ ret_code = mtd->_read_oob(mtd, from, ops);
+ else
+ ret_code = mtd->_read(mtd, from, ops->len, >retlen,
+ ops->datbuf);
+
/*
* In cases where ops->datbuf != NULL, mtd->_read_oob() has semantics
* similar to mtd->_read(), returning a non-negative integer
* representing max bitflips. In other cases, mtd->_read_oob() may
* return -EUCLEAN. In all cases, perform similar logic to mtd_read().
*/
- ret_code = mtd->_read_oob(mtd, from, ops);
if (unlikely(ret_code < 0))
return ret_code;
if (mtd->ecc_strength == 0)
@@ -1076,8 +1083,7 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
int ret;
ops->retlen = ops->oobretlen = 0;
- if (!mtd->_write_oob)
- return -EOPNOTSUPP;
+
if (!(mtd->flags & MTD_WRITEABLE))
return -EROFS;
@@ -1085,7 +1091,15 @@ int mtd_write_oob(struct mtd_info *mtd, loff_t to,
if (ret)
return ret;
- return mtd->_write_oob(mtd, to, ops);
+ /* Check the validity of a potential fallback on mtd->_write */
+ if ((!mtd->_write_oob) && (!mtd->_write || ops->oobbuf))
+ return -EOPNOTSUPP;
+
+ if (mtd->_write_oob)
+ return mtd->_write_oob(mtd, to, ops);
+ else
+ return mtd->_write(mtd, to, ops->len, >retlen,
+ ops->datbuf);
}
EXPORT_SYMBOL_GPL(mtd_write_oob);
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 01/21] mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
From: Boris Brezillon
Some MTD sublayers/drivers are implementing ->_read/write_oob() and
provide dummy wrappers for their ->_read/write() implementations.
Let the core handle this case instead of duplicating the logic.
Signed-off-by: Boris Brezillon
Acked-by: Robert Jarzmik
Acked-by: Brian Norris
Reviewed-by: Miquel Raynal
Tested-by: Ladislav Michl
Signed-off-by: Miquel Raynal
Reviewed-by: Jagan Teki
---
drivers/mtd/mtdcore.c | 31 ++--
drivers/mtd/mtdpart.c | 6 ++--
drivers/mtd/nand/nand_base.c | 56 ---
drivers/mtd/onenand/onenand_base.c | 60 --
4 files changed, 33 insertions(+), 120 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 2cda0511e8..15e0ac2f3e 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -938,7 +938,20 @@ int mtd_read(struct mtd_info *mtd, loff_t from, size_t
len, size_t *retlen,
* representing the maximum number of bitflips that were corrected on
* any one ecc region (if applicable; zero otherwise).
*/
- ret_code = mtd->_read(mtd, from, len, retlen, buf);
+ if (mtd->_read) {
+ ret_code = mtd->_read(mtd, from, len, retlen, buf);
+ } else if (mtd->_read_oob) {
+ struct mtd_oob_ops ops = {
+ .len = len,
+ .datbuf = buf,
+ };
+
+ ret_code = mtd->_read_oob(mtd, from, );
+ *retlen = ops.retlen;
+ } else {
+ return -ENOTSUPP;
+ }
+
if (unlikely(ret_code < 0))
return ret_code;
if (mtd->ecc_strength == 0)
@@ -953,10 +966,24 @@ int mtd_write(struct mtd_info *mtd, loff_t to, size_t
len, size_t *retlen,
*retlen = 0;
if (to < 0 || to > mtd->size || len > mtd->size - to)
return -EINVAL;
- if (!mtd->_write || !(mtd->flags & MTD_WRITEABLE))
+ if ((!mtd->_write && !mtd->_write_oob) ||
+ !(mtd->flags & MTD_WRITEABLE))
return -EROFS;
if (!len)
return 0;
+
+ if (!mtd->_write) {
+ struct mtd_oob_ops ops = {
+ .len = len,
+ .datbuf = (u8 *)buf,
+ };
+ int ret;
+
+ ret = mtd->_write_oob(mtd, to, );
+ *retlen = ops.retlen;
+ return ret;
+ }
+
return mtd->_write(mtd, to, len, retlen, buf);
}
EXPORT_SYMBOL_GPL(mtd_write);
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 5e42c4b833..3a3f2a1717 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -418,8 +418,10 @@ static struct mtd_part *allocate_partition(struct mtd_info
*master,
slave->mtd.dev.parent = master->dev.parent;
#endif
- slave->mtd._read = part_read;
- slave->mtd._write = part_write;
+ if (parent->_read)
+ slave->mtd._read = part_read;
+ if (parent->_write)
+ slave->mtd._write = part_write;
if (master->_panic_write)
slave->mtd._panic_write = part_panic_write;
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index eb9f121f81..8ebe85057d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1863,33 +1863,6 @@ read_retry:
return max_bitflips;
}
-/**
- * nand_read - [MTD Interface] MTD compatibility function for nand_do_read_ecc
- * @mtd: MTD device structure
- * @from: offset to read from
- * @len: number of bytes to read
- * @retlen: pointer to variable to store the number of read bytes
- * @buf: the databuffer to put data
- *
- * Get hold of the chip and call nand_do_read.
- */
-static int nand_read(struct mtd_info *mtd, loff_t from, size_t len,
-size_t *retlen, uint8_t *buf)
-{
- struct mtd_oob_ops ops;
- int ret;
-
- nand_get_device(mtd, FL_READING);
- memset(, 0, sizeof(ops));
- ops.len = len;
- ops.datbuf = buf;
- ops.mode = MTD_OPS_PLACE_OOB;
- ret = nand_do_read_ops(mtd, from, );
- *retlen = ops.retlen;
- nand_release_device(mtd);
- return ret;
-}
-
/**
* nand_read_oob_std - [REPLACEABLE] the most common OOB data read function
* @mtd: mtd info structure
@@ -2674,33 +2647,6 @@ static int panic_nand_write(struct mtd_info *mtd, loff_t
to, size_t len,
return ret;
}
-/**
- * nand_write - [MTD Interface] NAND write with ECC
- * @mtd: MTD device structure
- * @to: offset to write to
- * @len: number of bytes to write
- * @retlen: pointer to variable to store the number of written bytes
- * @buf: the data to write
- *
- * NAND write with ECC.
- */
-static int nand_write(struct mtd_info *mtd, loff_t to, size_t len,
- size_t *retlen, const uint8_t *buf)
-{
- struct mtd_oob_ops ops;
- int ret;
-
-
[U-Boot] [PATCH v2 00/21] SPI-NAND support
During the last months, Boris Brezillon shared his work to support
serial flashes within Linux. First, he delivered (and merged) a new
layer called spi-mem. He also initiated in Linux MTD subsystem the move
of all 'raw' NAND related code to a raw/ subdirectory, adding at the
same time a NAND core that would be shared with all NAND devices. Then,
he contributed a generic SPI-NAND driver, making use of this NAND core,
as well as some vendor code to drive a few chips.
On top of this work, I added an 'mtd' U-Boot command to handle all sort
of MTD devices. This should become the default command instead of having
one per flash flavor ('sf', 'nand', 'spi-nand' ?).
The series has been tested on an Ocelot board PCB123 (VSC7514),
featuring a Macronix SPI NAND chip.
TL;DR: the series contains:
- A few patches from Linux to resynchronize some areas of the MTD layer.
- Various fixes and re-organization of the MTD subsystem.
- The introduction of the SPI-mem interface.
- The addition of the generic SPI-NAND driver (and its bindings).
- Several SPI NAND chip drivers (Macronix, Micron, Winbond).
- A new 'mtd' command.
Any comments on the code, the organization and the respect of U-Boot
driver model will be welcome.
Thanks,
Miquèl
Changes since v1:
-
* Fixed the nand_memorg structure of the MX35LF2GE4AB chip.
* Added Reviewed-by tags from Jagan.
* Backported and squashed two patches fixing things in the SPI NAND core
received on the Linux ML.
* Backported more changes in mtdcore.c from Linux.
* Added a patch to add a fallback on mtd->_read/_write() in mtdcore.c
when mtd->_read/write_oob() is not supported.
* Removed the DT changes, useless as the DTs are not available in
mainline yet.
* Addressed Boris/Stefan comments on the 'mtd' command.
* Added support for multi-pages OOB read/write.
Boris Brezillon (7):
mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing
mtd: Add sanity checks in mtd_write/read_oob()
mtd: nand: Add core infrastructure to deal with NAND devices
mtd: nand: Pass mode information to nand_page_io_req
spi: Extend the core to ease integration of SPI memory controllers
mtd: spinand: Add initial support for the MX35LF1GE4AB chip
dt-bindings: Add bindings for SPI NAND devices
Brian Norris (1):
mtd: add get/set of_node/flash_node helpers
Ezequiel Garcia (1):
mtd: Uninline mtd_write_oob and move it to mtdcore.c
Frieder Schrempf (1):
mtd: spinand: Add initial support for Winbond W25M02GV
Miquel Raynal (9):
mtd: Fallback to ->_read/write() when ->_read/write_oob() is missing
mtd: fix build issue with includes
mtd: move definitions to enlarge their range
mtd: move all flash categories inside MTD submenu
mtd: move NAND fiels into a raw/ subdirectory
mtd: rename nand into rawnand in Kconfig prompt
mtd: spinand: Add initial support for the MX35LF2GE4AB chip
mtd: uclass: add probe function
cmd: mtd: add 'mtd' command
Peter Pan (2):
mtd: nand: Add core infrastructure to support SPI NANDs
mtd: spinand: Add initial support for Micron MT29F2G01ABAGD
cmd/Kconfig |5 +
cmd/Makefile |1 +
cmd/mtd.c | 287 ++
doc/device-tree-bindings/mtd/spi-nand.txt | 27 +
drivers/mtd/Kconfig |4 +-
drivers/mtd/Makefile |4 +-
drivers/mtd/mtd-uclass.c |9 +
drivers/mtd/mtdcore.c | 106 ++-
drivers/mtd/mtdcore.h |6 -
drivers/mtd/mtdpart.c |6 +-
drivers/mtd/nand/Kconfig | 241 +
drivers/mtd/nand/Makefile | 81 +-
drivers/mtd/nand/bbt.c| 132 +++
drivers/mtd/nand/core.c | 243 +
drivers/mtd/nand/raw/Kconfig | 239 +
drivers/mtd/nand/raw/Makefile | 78 ++
drivers/mtd/nand/{ => raw}/am335x_spl_bch.c |0
drivers/mtd/nand/{ => raw}/arasan_nfc.c |0
drivers/mtd/nand/{ => raw}/atmel_nand.c |0
drivers/mtd/nand/{ => raw}/atmel_nand_ecc.h |0
drivers/mtd/nand/{ => raw}/davinci_nand.c |0
drivers/mtd/nand/{ => raw}/denali.c |0
drivers/mtd/nand/{ => raw}/denali.h |0
drivers/mtd/nand/{ => raw}/denali_dt.c|0
drivers/mtd/nand/{ => raw}/denali_spl.c |0
drivers/mtd/nand/{ => raw}/fsl_elbc_nand.c|0
drivers/mtd/nand/{ => raw}/fsl_elbc_spl.c |0
drivers/mtd/nand/{ => raw}/fsl_ifc_nand.c |0
drivers/mtd/nand/{ => raw}/fsl_ifc_spl.c |0
drivers/mtd/nand/{ => raw}/fsl_upm.c |0
drivers/mtd/nand/{ => raw}/fsmc_nand.c|0
drivers/mtd/nand/{ => raw}/kb9202_nand.c |0
drivers/mtd/nand/{ => raw}/kirkwood_nand.c|0
drivers/mtd/nand/{ => raw}/kmeter1_nand.c |0
drivers/mtd/nand/{ =>
Re: [U-Boot] [PATCH 0/4] fix propagation of flags from do_env_default()
Gentle ping. On 06/24/2018 07:16 PM, Yaniv Levinsky wrote: > The function do_env_default() doesn't propagate flags to himport_r(). It > causes > the "-f" option to have no effect on the execution of "env default" commands. > > Fix the call paths from do_env_default() to himport_r() to pass flags > correctly. > > Yaniv Levinsky (4): > cmd: nvedit: rename flags in do_env_default > cmd: nvedit: propagate envflag to set_default_vars > cmd: nvedit: set H_INTERACTIVE in do_env_default > env: common: accept flags on reset to default env > > arch/arm/mach-imx/mx6/opos6ul.c | 2 +- > cmd/nvedit.c| 11 ++- > common/board_r.c| 2 +- > common/spl/spl_dfu.c| 2 +- > env/common.c| 27 --- > env/ext4.c | 2 +- > env/fat.c | 2 +- > env/mmc.c | 12 ++-- > env/nand.c | 6 +++--- > env/sata.c | 2 +- > env/sf.c| 10 +- > env/ubi.c | 6 +++--- > include/environment.h | 4 ++-- > 13 files changed, 43 insertions(+), 45 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 10/20] spi: Extend the core to ease integration of SPI memory controllers
Hi Jagan, Jagan Teki wrote on Wed, 11 Jul 2018 20:07:19 +0530: > On Wed, Jul 11, 2018 at 7:25 PM, Miquel Raynal > wrote: > > Hi Jagan, > > > > Jagan Teki wrote on Fri, 6 Jul 2018 17:02:22 > > +0530: > > > >> On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal > >> wrote: > >> > From: Boris Brezillon > >> > > >> > Some controllers are exposing high-level interfaces to access various > >> > kind of SPI memories. Unfortunately they do not fit in the current > >> > spi_controller model and usually have drivers placed in > >> > drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI > >> > memories in general. > >> > > >> > This is an attempt at defining a SPI memory interface which works for > >> > all kinds of SPI memories (NORs, NANDs, SRAMs). > >> > > >> > Signed-off-by: Boris Brezillon > >> > Signed-off-by: Miquel Raynal > >> > --- > >> > drivers/spi/Kconfig | 7 + > >> > drivers/spi/Makefile | 1 + > >> > drivers/spi/spi-mem.c | 500 > >> > ++ > >> > include/spi-mem.h | 258 ++ > >> > include/spi.h | 11 ++ > >> > 5 files changed, 777 insertions(+) > >> > create mode 100644 drivers/spi/spi-mem.c > >> > create mode 100644 include/spi-mem.h > >> > > >> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > >> > index 235a8c7d73..0ee371b2d9 100644 > >> > --- a/drivers/spi/Kconfig > >> > +++ b/drivers/spi/Kconfig > >> > @@ -15,6 +15,13 @@ config DM_SPI > >> > > >> > if DM_SPI > >> > > >> > +config SPI_MEM > >> > + bool "SPI memory extension" > >> > + help > >> > + Enable this option if you want to enable the SPI memory > >> > extension. > >> > + This extension is meant to simplify interaction with SPI > >> > memories > >> > + by providing an high-level interface to send memory-like > >> > commands. > >> > + > >> > config ALTERA_SPI > >> > bool "Altera SPI driver" > >> > help > >> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > >> > index 4b6000fd9a..982529a0e6 100644 > >> > --- a/drivers/spi/Makefile > >> > +++ b/drivers/spi/Makefile > >> > @@ -10,6 +10,7 @@ ifdef CONFIG_DM_SPI > >> > obj-y += spi-uclass.o > >> > obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o > >> > obj-$(CONFIG_SOFT_SPI) += soft_spi.o > >> > +obj-$(CONFIG_SPI_MEM) += spi-mem.o > >> > else > >> > obj-y += spi.o > >> > obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o > >> > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c > >> > new file mode 100644 > >> > index 00..1aabe56819 > >> > --- /dev/null > >> > +++ b/drivers/spi/spi-mem.c > >> > @@ -0,0 +1,500 @@ > >> > +// SPDX-License-Identifier: GPL-2.0+ > >> > +/* > >> > + * Copyright (C) 2018 Exceet Electronics GmbH > >> > + * Copyright (C) 2018 Bootlin > >> > + * > >> > + * Author: Boris Brezillon > >> > + */ > >> > + > >> > +#ifndef __UBOOT__ > >> > +#include > >> > +#include > >> > +#include "internals.h" > >> > +#else > >> > +#include > >> > +#include > >> > +#endif > >> > + > >> > +#ifndef __UBOOT__ > >> > >> I would like remove Linux stuff atleast on this file becuase it's > >> difficult for me to read or review the code and also driver/spi have > >> fully u-boot dm stuff. I know it's easy for Linux sync but for this we > >> can do manual sync what ever need. I'm on something what from Linux. > > > > I'm not sure this is a wise idea. > > > > And I don't understand how "driver/spi have fully u-boot dm stuff" is > > related in any manner to this request. > > The code in driver/spi is more or less u-boot code it doesn't have > Linux sync. ie reason I want to maintain the similar integrity here, > but on the other-side spi-mem depend more on Linux like MTD. OK let's > move as-it-is like what you added, may be we can simulate if require > in future need. I understand better your POV, OK then, let met re-add these portions. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH] usb: dwc3: convert to livetree
On 06/11/2018 11:39 AM, Vipul Kumar wrote: > Update the DWC3 USB driver to support a live tree. > > Signed-off-by: Vipul Kumar What about systems which do not use live tree, does it work on those ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] Make U-Boot log great again
On Tue, Jul 10, 2018 at 5:38 PM, Tom Rini wrote: > On Tue, Jul 10, 2018 at 11:01:14AM +0800, Bin Meng wrote: >> Hello, >> >> On Fri, Mar 23, 2018 at 1:44 PM, Bin Meng wrote: >> > Hi, >> > >> > On Sat, Feb 17, 2018 at 3:49 AM, Robert Nelson >> > wrote: >> >> On Fri, Feb 16, 2018 at 1:01 PM, Sam Protsenko >> >> wrote: >> >>> Hi guys, >> >>> >> >>> TL;DR This is a suggestion about fixing U-Boot log, which has got >> >>> worse recently. >> >>> >> >>> Right now U-Boot and SPL logs are cluttered with bogus warnings like >> >>> these (on X15 board, but I'm pretty sure it should appear on many >> >>> others): >> >>> >> >>> Loading Environment from FAT... >> >>> *** Warning - bad CRC, using default environment >> >>> Failed (-5) >> >> >> > >> > Do we plan to fix this "Failed (-5)" message? It's very confusing. >> > Like previous U-Boot just printing "*** Warning - bad CRC, using >> > default environment" is enough I think. >> > >> >> The v2018.07 release still has this "Failed (-5)" message on boot. >> When do we plan to fix this? > > I don't mean for this to sound glib, but I was expecting patches to get > posted to change this particular area at least. I thought it had been > talked to the point where it was understood what the next steps should > look like? Thanks/sorry! > Ok, as nobody volunteered, I'll look into this in my spare time. This thread has all sorts of suggestions, not only about error messages. I guess we need to see some code to have more meaningful discussion. Let me prepare some patch, and then we can discuss if it's a way to go. Thanks. > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
Relocate watchdog ops as was done by:
"dm: Add support for all targets which requires MANUAL_RELOC"
(sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3)
Signed-off-by: Michal Simek
---
based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html
---
drivers/watchdog/wdt-uclass.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index f6f2fe3739d3..23b7e3360d32 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -63,8 +63,31 @@ int wdt_expire_now(struct udevice *dev, ulong flags)
return ret;
}
+static int wdt_post_bind(struct udevice *dev)
+{
+#if defined(CONFIG_NEEDS_MANUAL_RELOC)
+ struct wdt_ops *ops = (struct wdt_ops *)device_get_ops(dev);
+ static int reloc_done;
+
+ if (!reloc_done) {
+ if (ops->start)
+ ops->start += gd->reloc_off;
+ if (ops->stop)
+ ops->stop += gd->reloc_off;
+ if (ops->reset)
+ ops->reset += gd->reloc_off;
+ if (ops->expire_now)
+ ops->expire_now += gd->reloc_off;
+
+ reloc_done++;
+ }
+#endif
+ return 0;
+}
+
UCLASS_DRIVER(wdt) = {
.id = UCLASS_WDT,
.name = "watchdog",
.flags = DM_UC_FLAG_SEQ_ALIAS,
+ .post_bind = wdt_post_bind,
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 10/20] spi: Extend the core to ease integration of SPI memory controllers
On Wed, Jul 11, 2018 at 7:25 PM, Miquel Raynal wrote: > Hi Jagan, > > Jagan Teki wrote on Fri, 6 Jul 2018 17:02:22 > +0530: > >> On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal >> wrote: >> > From: Boris Brezillon >> > >> > Some controllers are exposing high-level interfaces to access various >> > kind of SPI memories. Unfortunately they do not fit in the current >> > spi_controller model and usually have drivers placed in >> > drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI >> > memories in general. >> > >> > This is an attempt at defining a SPI memory interface which works for >> > all kinds of SPI memories (NORs, NANDs, SRAMs). >> > >> > Signed-off-by: Boris Brezillon >> > Signed-off-by: Miquel Raynal >> > --- >> > drivers/spi/Kconfig | 7 + >> > drivers/spi/Makefile | 1 + >> > drivers/spi/spi-mem.c | 500 >> > ++ >> > include/spi-mem.h | 258 ++ >> > include/spi.h | 11 ++ >> > 5 files changed, 777 insertions(+) >> > create mode 100644 drivers/spi/spi-mem.c >> > create mode 100644 include/spi-mem.h >> > >> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig >> > index 235a8c7d73..0ee371b2d9 100644 >> > --- a/drivers/spi/Kconfig >> > +++ b/drivers/spi/Kconfig >> > @@ -15,6 +15,13 @@ config DM_SPI >> > >> > if DM_SPI >> > >> > +config SPI_MEM >> > + bool "SPI memory extension" >> > + help >> > + Enable this option if you want to enable the SPI memory >> > extension. >> > + This extension is meant to simplify interaction with SPI memories >> > + by providing an high-level interface to send memory-like >> > commands. >> > + >> > config ALTERA_SPI >> > bool "Altera SPI driver" >> > help >> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile >> > index 4b6000fd9a..982529a0e6 100644 >> > --- a/drivers/spi/Makefile >> > +++ b/drivers/spi/Makefile >> > @@ -10,6 +10,7 @@ ifdef CONFIG_DM_SPI >> > obj-y += spi-uclass.o >> > obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o >> > obj-$(CONFIG_SOFT_SPI) += soft_spi.o >> > +obj-$(CONFIG_SPI_MEM) += spi-mem.o >> > else >> > obj-y += spi.o >> > obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o >> > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c >> > new file mode 100644 >> > index 00..1aabe56819 >> > --- /dev/null >> > +++ b/drivers/spi/spi-mem.c >> > @@ -0,0 +1,500 @@ >> > +// SPDX-License-Identifier: GPL-2.0+ >> > +/* >> > + * Copyright (C) 2018 Exceet Electronics GmbH >> > + * Copyright (C) 2018 Bootlin >> > + * >> > + * Author: Boris Brezillon >> > + */ >> > + >> > +#ifndef __UBOOT__ >> > +#include >> > +#include >> > +#include "internals.h" >> > +#else >> > +#include >> > +#include >> > +#endif >> > + >> > +#ifndef __UBOOT__ >> >> I would like remove Linux stuff atleast on this file becuase it's >> difficult for me to read or review the code and also driver/spi have >> fully u-boot dm stuff. I know it's easy for Linux sync but for this we >> can do manual sync what ever need. I'm on something what from Linux. > > I'm not sure this is a wise idea. > > And I don't understand how "driver/spi have fully u-boot dm stuff" is > related in any manner to this request. The code in driver/spi is more or less u-boot code it doesn't have Linux sync. ie reason I want to maintain the similar integrity here, but on the other-side spi-mem depend more on Linux like MTD. OK let's move as-it-is like what you added, may be we can simulate if require in future need. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] microblaze: Do not call timer init that early
Timer needs to be converted to DM but as of now it can't be called so
early because intc controller is not ready. Call it later in board_r.c.
Before this patch timer_init is called twice which is wrong.
Signed-off-by: Michal Simek
---
common/board_f.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index e943347ce3df..ccca794fc82b 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -775,7 +775,7 @@ static const init_fnc_t init_sequence_f[] = {
/* get CPU and bus clocks according to the environment variable */
get_clocks, /* get CPU and bus clocks (etc.) */
#endif
-#if !defined(CONFIG_M68K)
+#if !defined(CONFIG_MICROBLAZE) && !defined(CONFIG_M68K)
timer_init, /* initialize timer */
#endif
#if defined(CONFIG_BOARD_POSTCLK_INIT)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 5/6] microblaze: Support for watchdog_reset in Microblaze init
On 29.6.2018 23:51, Shreenidhi Shedi wrote:
> Signed-off-by: Shreenidhi Shedi
> ---
>
> Changes in v1: None
>
> .../microblaze-generic/microblaze-generic.c | 43 +--
> 1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c
> b/board/xilinx/microblaze-generic/microblaze-generic.c
> index 7d8f247fa9..1d48bfb20e 100644
> --- a/board/xilinx/microblaze-generic/microblaze-generic.c
> +++ b/board/xilinx/microblaze-generic/microblaze-generic.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -24,6 +25,12 @@ DECLARE_GLOBAL_DATA_PTR;
> static int reset_pin = -1;
> #endif
>
> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_XILINX_TB_WATCHDOG)
CONFIG_WDT here because it doesn't need to be just XILINX_TB.
> +#include
Please move this header out of if - it is not needed.
> +
> +static struct udevice *watchdog_dev;
> +#endif /* !CONFIG_SPL_BUILD && CONFIG_XILINX_TB_WATCHDOG */
> +
> ulong ram_base;
>
> int dram_init_banksize(void)
> @@ -68,10 +75,6 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
> const argv[])
> if (reset_pin != -1)
> gpio_direction_output(reset_pin, 1);
> #endif
> -
> -#ifdef CONFIG_XILINX_TB_WATCHDOG
> - hw_watchdog_disable();
> -#endif
> #endif
> puts("Resetting board\n");
> __asm__ __volatile__ (" mts rmsr, r0;" \
> @@ -91,9 +94,41 @@ static int gpio_init(void)
> return 0;
> }
>
> +#ifdef CONFIG_XILINX_TB_WATCHDOG
CONFIG_WATCHDOG here.
> +/* Called by macro WATCHDOG_RESET */
> +void watchdog_reset(void)
> +{
> +#if !defined(CONFIG_SPL_BUILD)
> + ulong now;
> + static ulong next_reset;
> +
> + if (!watchdog_dev)
> + return;
> +
> + now = timer_get_us();
> +
> + /* Do not reset the watchdog too often */
> + if (now > next_reset) {
> + wdt_reset(watchdog_dev);
> + next_reset = now + 1000;
> + }
> +#endif /* !CONFIG_SPL_BUILD */
> +}
> +#endif /* CONFIG_XILINX_TB_WATCHDOG */
> +
> int board_late_init(void)
> {
> gpio_init();
>
> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_XILINX_TB_WATCHDOG)
CONFIG_WDT here.
> + watchdog_dev = NULL;
> + if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
> + puts("Watchdog: Not found!\n");
> + } else {
> + wdt_start(watchdog_dev, 0, 0);
> + puts("Watchdog: Started\n");
> + }
I have sent today update on this code for zynq and zynqmp. And I hope
that this will be accepted to get this code to work properly.
https://lists.denx.de/pipermail/u-boot/2018-July/334227.html
if (uclass_get_device_by_seq(UCLASS_WDT, 0, _dev)) {
debug("Watchdog: Not found by seq!\n");
if (uclass_get_device(UCLASS_WDT, 0, _dev)) {
puts("Watchdog: Not found!\n");
return 0;
}
}
wdt_start(watchdog_dev, 0, 0);
puts("Watchdog: Started\n");
> +#endif /* !CONFIG_SPL_BUILD && CONFIG_XILINX_TB_WATCHDOG */
> +
> return 0;
> }
>
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 6/6] watchdog: Convert Xilinx Axi watchdog driver to driver model
please fill commit message.
On 29.6.2018 23:51, Shreenidhi Shedi wrote:
> Signed-off-by: Shreenidhi Shedi
> ---
>
> Changes in v1: None
>
> drivers/watchdog/Kconfig | 8 +++
> drivers/watchdog/xilinx_tb_wdt.c | 107 ---
> 2 files changed, 91 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 148c6a0d68..351d2af8d9 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -103,4 +103,12 @@ config WDT_CDNS
> Select this to enable Cadence watchdog timer, which can be found on
> some
> Xilinx Microzed Platform.
>
> +config XILINX_TB_WATCHDOG
> + bool "Xilinx Axi watchdog timer support"
> + depends on WDT
> + imply WATCHDOG
> + help
> +Select this to enable Xilinx Axi watchdog timer, which can be found
> on some
> +Xilinx Microblaze Platform.
> +
> endmenu
> diff --git a/drivers/watchdog/xilinx_tb_wdt.c
> b/drivers/watchdog/xilinx_tb_wdt.c
> index 2274123e49..7f20c2ce2f 100644
> --- a/drivers/watchdog/xilinx_tb_wdt.c
> +++ b/drivers/watchdog/xilinx_tb_wdt.c
> @@ -1,13 +1,17 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> + * Xilinx Axi platforms watchdog timer driver.
> + *
> + * Author(s):Michal Šimek
> + * Shreenidhi Shedi
> + *
> * Copyright (c) 2011-2013 Xilinx Inc.
> */
>
> #include
> -#include
> -#include
> -#include
> -#include
> +#include
> +#include
> +#include
>
> #define XWT_CSR0_WRS_MASK0x0008 /* Reset status Mask */
> #define XWT_CSR0_WDS_MASK0x0004 /* Timer state Mask */
> @@ -20,49 +24,104 @@ struct watchdog_regs {
> u32 tbr; /* 0x8 */
> };
>
> -static struct watchdog_regs *watchdog_base =
> - (struct watchdog_regs *)CONFIG_WATCHDOG_BASEADDR;
> +struct xlnx_wdt_priv {
> + bool enable_once;
> + struct watchdog_regs *regs;
> +};
>
> -void hw_watchdog_reset(void)
> +static int xlnx_wdt_reset(struct udevice *dev)
> {
> u32 reg;
> + struct xlnx_wdt_priv *priv = dev_get_priv(dev);
> +
> + debug("%s\n", __func__);
>
> /* Read the current contents of TCSR0 */
> - reg = readl(_base->twcsr0);
> + reg = readl(>regs->twcsr0);
>
> /* Clear the watchdog WDS bit */
> if (reg & (XWT_CSR0_EWDT1_MASK | XWT_CSRX_EWDT2_MASK))
> - writel(reg | XWT_CSR0_WDS_MASK, _base->twcsr0);
> + writel(reg | XWT_CSR0_WDS_MASK, >regs->twcsr0);
> +
> + return 0;
> }
>
> -void hw_watchdog_disable(void)
> +static int xlnx_wdt_stop(struct udevice *dev)
> {
> u32 reg;
> + struct xlnx_wdt_priv *priv = dev_get_priv(dev);
> +
> + if (priv->enable_once) {
> + puts("Can't stop Xilinux Axi watchdog.\n");
Just Xilinx here.
> + return -1;
> + }
>
> /* Read the current contents of TCSR0 */
> - reg = readl(_base->twcsr0);
> + reg = readl(>regs->twcsr0);
>
> - writel(reg & ~XWT_CSR0_EWDT1_MASK, _base->twcsr0);
> - writel(~XWT_CSRX_EWDT2_MASK, _base->twcsr1);
> + writel(reg & ~XWT_CSR0_EWDT1_MASK, >regs->twcsr0);
> + writel(~XWT_CSRX_EWDT2_MASK, >regs->twcsr1);
>
> puts("Watchdog disabled!\n");
> +
> + return 0;
> }
>
> -static void hw_watchdog_isr(void *arg)
> +static int xlnx_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
> {
> - hw_watchdog_reset();
> + struct xlnx_wdt_priv *priv = dev_get_priv(dev);
> +
> + writel((XWT_CSR0_WRS_MASK | XWT_CSR0_WDS_MASK | XWT_CSR0_EWDT1_MASK),
> +>regs->twcsr0);
> +
> + writel(XWT_CSRX_EWDT2_MASK, >regs->twcsr1);
> +
> + return 0;
> }
>
> -void hw_watchdog_init(void)
> +static int xlnx_wdt_probe(struct udevice *dev)
> {
> - int ret;
> + debug("%s: Probing wdt%u\n", __func__, dev->seq);
>
> - writel((XWT_CSR0_WRS_MASK | XWT_CSR0_WDS_MASK | XWT_CSR0_EWDT1_MASK),
> -_base->twcsr0);
> - writel(XWT_CSRX_EWDT2_MASK, _base->twcsr1);
> + xlnx_wdt_stop(dev);
Based on what I see on running microblaze system. Watchdog is started
right after bitstream is loaded. It is weird that you want to stop
watchdog which is not started yet.
Also in case you can disable it because it was enabled in previous code
you are no covering time between probe done and watchdog enabling again.
That's why I think you should remove this line.
>
> - ret = install_interrupt_handler(CONFIG_WATCHDOG_IRQ,
> - hw_watchdog_isr, NULL);
> - if (ret)
> - puts("Watchdog IRQ registration failed.");
> + return 0;
> }
> +
> +static int xlnx_wdt_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct xlnx_wdt_priv *priv = dev_get_priv(dev);
> +
> + priv->regs = (struct watchdog_regs *)dev_read_addr(dev);
> + if (IS_ERR(priv->regs))
> + return PTR_ERR(priv->regs);
> +
> + priv->enable_once = dev_read_u32_default(dev, "xlnx,wdt-enable-once",
> +
Re: [U-Boot] [PATCH v4 3/6] block: Add a function to find block device descriptor
On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> Hi Tien,
>
> On 6 July 2018 at 02:26, wrote:
> >
> > From: Tien Fong Chee
> >
> > Add a function to find the block device descriptor of the parent
> > device.
> >
> > Signed-off-by: Tien Fong Chee
> > ---
> > drivers/block/blk-uclass.c | 23 +++
> > include/blk.h | 9 +
> > 2 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-
> > uclass.c
> > index 9e0c823..facf527 100644
> > --- a/drivers/block/blk-uclass.c
> > +++ b/drivers/block/blk-uclass.c
> > @@ -132,6 +132,29 @@ struct blk_desc
> > *blk_get_devnum_by_typename(const char *if_typename, int devnum)
> > }
> >
> > /**
> > + * blk_get_by_device() - Get the block device descriptor for the
> > given device
> > + * @dev: Instance of a storage device
> > + *
> > + * Return: With block device descriptor on success , NULL if there
> > is no such
> > + *block device.
> > + */
> > +struct blk_desc *blk_get_by_device(struct udevice *dev)
> > +{
> > + struct udevice *child_dev, *next;
> > +
> > + device_foreach_child_safe(child_dev, next, dev) {
> > + if (device_get_uclass_id(child_dev) != UCLASS_BLK)
> > + continue;
> > +
> > + return dev_get_uclass_platdata(child_dev);
> > + }
> > +
> > + debug("%s: No block device found\n", __func__);
> > +
> > + return NULL;
> > +}
> Is this different from blk_get_from_parent() ?
This new function would return block description.
blk_get_from_parents() would return child device.
>
> [..]
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/6] doc: Add new doc for file system firmware loader driver model
On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> Hi Tien,
>
> On 6 July 2018 at 02:27, wrote:
> >
> > From: Tien Fong Chee
> >
> > Provide information about
> >
> > - overview of file system firmware loader driver model
> > - describe storage device and partition in device tree source
> > - describe fie system firmware loader API
> >
> > Signed-off-by: Tien Fong Chee
> > ---
> > doc/driver-model/fs_firmware_loader.txt | 133
> >
> > 1 file changed, 133 insertions(+)
> > create mode 100644 doc/driver-model/fs_firmware_loader.txt
> Reviewed-by: Simon Glass
>
> A few comments below.
>
> >
> >
> > diff --git a/doc/driver-model/fs_firmware_loader.txt b/doc/driver-
> > model/fs_firmware_loader.txt
> > new file mode 100644
> > index 000..290915a
> > --- /dev/null
> > +++ b/doc/driver-model/fs_firmware_loader.txt
> > @@ -0,0 +1,133 @@
> > +# Copyright (C) 2018 Intel Corporation
> > +#
> > +# SPDX-License-Identifier:GPL-2.0
> > +
> > +Introduction
> > +
> > +
> > +This is file system firmware loader for U-Boot framework, which
> > has very close
> > +to some Linux Firmware API. For the details of Linux Firmware API,
> > you can refer
> > +to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/i
> > ndex.html.
> > +
> > +File system firmware loader can be used to load whatever(firmware,
> > image,
> > +and binary) from the storage device in file system format into
> > target location
> > +such as memory, then consumer driver such as FPGA driver can
> > program FPGA image
> > +from the target location into FPGA.
> > +
> > +To enable firmware loader, CONFIG_FS_LOADER need to be set at
> > +_defconfig such as "CONFIG_FS_LOADER=y".
> > +
> > +Firmware Loader API core features
> > +-
> > +
> > +Firmware storage device described in device tree source
> > +---
> > + For passing data like storage device phandle and partition
> > where the
> > + firmware loading from to the firmware loader driver, those
> > data could be
> > + defined in fs-loader node as shown in below:
> > +
> > + Example for block device:
> > + fs_loader0: fs-loader@0 {
> > + u-boot,dm-pre-reloc;
> > + compatible = "u-boot,fs-loader";
> > + phandlepart = < 1>;
> I don't like this name much. How about
>
> source-partition = < 1>;
Okay.
>
> or something like that?
>
> >
> > + };
> > +
> > + < 1> means block storage device pointer and its
> > partition.
> > +
> > + Above example is a description for block storage, but for
> > UBI storage
> > + device, it can be described in FDT as shown in below:
> > +
> > + Example for ubi:
> > + fs_loader1: fs-loader@1 {
> > + u-boot,dm-pre-reloc;
> > + compatible = "u-boot,fs-loader";
> > + mtdpart = "UBI",
> > + ubivol = "ubi0";
> > + };
> > +
> > + Then, firmware_loader property would be set with the path
> > of fs_loader
> > + node under /chosen node such as:
> > + /{
> > + chosen {
> > + firmware_loader = _loader0;
> > + };
> > + };
> > +
> > + However, this driver is also designed to support U-boot
> > environment
> U-Boot
>
> Please fix below also.
Okay.
>
> >
> > + variables, so all these data from FDT can be overwritten
> > + through the U-boot environment variable during run time.
> > + For examples:
> > + "storage_interface" - Storage interface, it can be "mmc",
> > "usb", "sata"
> > + or "ubi".
> > + "fw_dev_part" - Block device number and its partition, it
> > can be "0:1".
> > + "fw_ubi_mtdpart" - UBI device mtd partition, it can be
> > "UBI".
> > + "fw_ubi_volume" - UBI volume, it can be "ubi0".
> > +
> > + When above environment variables are set, environment
> > values would be
> > + used instead of data from FDT.
> > + The benefit of this design allows user to change storage
> > attribute data
> > + at run time through U-boot console and saving the setting
> > as default
> > + environment values in the storage for the next power cycle,
> > so no
> > + compilation is required for both driver and FDT.
> > +
> > +File system firmware Loader API
> > +---
> > +
> > +int request_firmware_into_buf(struct device_platdata *plat,
> > +const char *name,
> > +void *buf, size_t size, u32
> > offset,
> > +struct firmware **firmwarep)
> > +
> >
> > +Load firmware into a previously allocated buffer
> > +
> > +Parameters:
> > +
> > +1. struct device_platdata *plat
> > + Platform
Re: [U-Boot] [PATCH v4 5/6] doc: dtbinding: Add file system firmware loader binding document
On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote: > On 6 July 2018 at 02:27, wrote: > > > > From: Tien Fong Chee > > > > Add a document to describe file system firmware loader binding > > information. > > > > Signed-off-by: Tien Fong Chee > > --- > > doc/device-tree-bindings/chosen.txt | 21 + > > doc/device-tree-bindings/misc/fs_loader.txt | 48 > > + > > 2 files changed, 69 insertions(+) > > create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt > Reviewed-by: Simon Glass > > Apart from the naming of phandlepart, as I mentioned in the previous > patch Noted. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote: > Hi Tien, > > On 6 July 2018 at 02:28, wrote: > > > > From: Tien Fong Chee > > > > This is file system generic loader which can be used to load > > the file image from the storage into target such as memory. > > The consumer driver would then use this loader to program whatever, > > ie. the FPGA device. > > > > Signed-off-by: Tien Fong Chee > > --- > > drivers/misc/Kconfig | 10 ++ > > drivers/misc/Makefile| 1 + > > drivers/misc/fs_loader.c | 295 > > +++ > > include/dm/uclass-id.h | 1 + > > include/fs_loader.h | 79 + > > 5 files changed, 386 insertions(+) > > create mode 100644 drivers/misc/fs_loader.c > > create mode 100644 include/fs_loader.h > I don't see a sandbox test for this. We need to add a test for every > new uclass. Please let me know if you want some pointers to ideas. > Yeah, i will add the sandbox for this once we finalize the design. Sandbox is new to me, i would appreciate it very much if you can share some ideas. > [..] > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 17/20] cmd: mtd: add 'mtd' command
Hi Boris,
Boris Brezillon wrote on Wed, 11 Jul 2018
16:01:09 +0200:
> On Wed, 11 Jul 2018 15:51:39 +0200
> Miquel Raynal wrote:
>
> > > > +
> > > > + argc -= 3;
> > > > + argv += 3;
> > > > +
> > > > + /* Do the parsing */
> > > > + if (!strncmp(cmd, "read", 4) || !strncmp(cmd, "write", 5)) {
> > > > + bool read, raw, woob;
> > > > + uint *waddr = NULL;
> > > > + u64 off, len;
> > > > +
> > > > + read = !strncmp(cmd, "read", 4);
> > > > + raw = strstr(cmd, ".raw");
> > > > + woob = strstr(cmd, ".oob");
> > > > +
> > > > + if (!read) {
> > > > + if (argc < 1)
> > > > + return CMD_RET_USAGE;
> > > > +
> > > > + waddr = map_sysmem(simple_strtoul(argv[0],
> > > > NULL, 10),
> > > > + 0);
> > > > + argc--;
> > > > + argv++;
> > > > + }
> > > > +
> > > > + off = argc > 0 ? simple_strtoul(argv[0], NULL, 10) : 0;
> > > > + len = argc > 1 ? simple_strtoul(argv[1], NULL, 10) :
> > > > +mtd->writesize + (woob ? mtd->oobsize
> > > > : 0);
> > > > +
> > > > + if ((u32)off % mtd->writesize) {
> > > > + printf("Section not page-aligned (0x%x)\n",
> > > > + mtd->writesize);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (woob && (len != (mtd->writesize + mtd->oobsize))) {
> > > > + printf("OOB operations are limited to single
> > > > pages\n");
> > > > + return -EINVAL;
> > > > + }
> > >
> > > Is this a uboot limitation? I don't think you have such a limitation in
> > > Linux.
> >
> > Kind of, only one single page write with OOB at a time is possible
> > says a comment on mtd_oob_ops in mtd.h in Linux. Reads are actually not
> > limited. But I really prefer to keep this limitation that simplifies _a
> > lot_ the logic and is not really useful to a u-boot user I suppose.
>
> It is useful when you write things in raw mode and the image you write
> contains OOB (which in turn contains pre-generated ECC bytes). I know we
> do such things on sunxi when writing the SPL.
:'(
Ok.
>
> >
> > >
> > > > +
> > > > + if ((off + len) >= mtd->size) {
> > >
> > > That doesn't work when reading the last page of the MTD device with
> > > woob = true. See how Linux handle that here [1]. BTW, why don't you let
> > > mtdcore.c do these checks for you (that's also true for unaligned
> > > accesses)?
> >
> > Because the relevant patch (and its fix :) ) has not been backported
> > yet.
> >
> > And now I understand your voice in my ears "do it".
>
> Hehe. So I guess I'll see this patch in your v2 :-).
Indeed ;)
Cheers,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Kconfiglib documentation generation
Hello, Just as an FYI, Kconfiglib 2 (https://github.com/ulfalizer/kconfiglib) can generate nice Kconfig docs. See http://docs.zephyrproject.org/reference/kconfig/index.html for example output (warning: heavy page, lots of symbols). The script that generates the RST output for those docs is at https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/scripts/genrest.py. It deals well with symbols defined in multiple locations as well (plenty of those in Zephyr too), listing each definition with the correct properties. I just added a patch to Kconfiglib that reduces the parsing time for the U-Boot Kconfigs from about four seconds to about half a second as well (Core i7 2600k). Those symbols defined in a million locations triggered some redundant work earlier. :) Cheers, Ulf ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 07/11/2018 03:56 PM, Jason Rush wrote: > On 7/11/2018 8:48 AM, Marek Vasut wrote: >> On 07/11/2018 03:49 PM, Jason Rush wrote: >>> On 7/11/2018 3:55 AM, Marek Vasut wrote: On 07/11/2018 05:11 AM, Jason Rush wrote: [...] > However, if I press the HPS_RST push button on the SoCKit (which is > connected > to power on reset), occasionally U-Boot will lock up while booting. > It always > boots and operates correctly from the initial power on, but it almost > always > fails to boot after pressing the HPS_RST button. > > Usually after pressing the HPS_RST button, U-Boot makes it past the > SPL, and > hangs somewhere after the call to setup_reloc() in > ./common/board_f.c. Once > it hangs there, pressing the HPS_RST button again usually causes the > SPL to > hang while setting up the MMU (before my call to memset). Eventually > the > WDT kicks in, and it just keeps hanging up in the same place. Once > it gets in > this mode, the only way to recover it is by toggling power on the > board. > > I spent a bunch of time today trying to track down where it was > hanging, but > I couldn't pin point anything. The MMU tables looked correct. The > MMU > registers looked good. I'm not sure the best way to debug what's > going on. Try triggering warm reset and cold reset via the reset register: mw 0xffd05004 1 mw 0xffd05004 2 Does it hang in one case and not in the other ? >>> It hangs in both cases. >>> >>> I did find that if I do not metset the last 1MiB of DRAM with the cache >>> on, >>> both warm and cold resets work. >>> >>> I changed the ecc scrubbing to zero out the first 0x8000 bytes and the >>> last >>> 0x1 bytes before the MMU is setup and I enable dcache. Then with >>> the dcache enabled, I zero out the rest of memory. The resets work in >>> this >>> case as well. So there seems to be some side effect of clearing out the >>> relocate address space with the cache on. >> Can you investigate ? >> > I'd be happy to investigate more, but I'm not really sure what > my next step should be. > > Something appears to be happening differently when U-Boot > relocates if the dcache is on. But don't know how to track it > down. IIRC I disabled cache after scrubbing. >>> My mistake. I did disable the dcache after scrubbing too. The >>> code is almost identical to the Arria10 code where after >>> scrubbing it flushes the dcache, then turns it off. >>> >>> The weird reset problems happens if I scrub the area where >>> u-boot relocates to with the dcache on, then turn dcache off. >>> >>> I tried to also tried turning the MMU off, but that didn't help. >> Maybe there are some data used by the SPL there ? I think the SPL has >> malloc area in RAM at some point. >> > I thought something similar, so I narrowed it down to clearing > just from where U-Boot relocates to the end of DRAM. If I'm > correct, that includes where U-Boot relocates and where the > MMU tables are normally stored. Hm, although, I think if you do the scrubbing right after the DRAM controller gets inited, there isn't anything in the DRAM yet. You might need to keep digging, since this is odd. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
Hi Tien, On 6 July 2018 at 02:28, wrote: > From: Tien Fong Chee > > This is file system generic loader which can be used to load > the file image from the storage into target such as memory. > The consumer driver would then use this loader to program whatever, > ie. the FPGA device. > > Signed-off-by: Tien Fong Chee > --- > drivers/misc/Kconfig | 10 ++ > drivers/misc/Makefile| 1 + > drivers/misc/fs_loader.c | 295 > +++ > include/dm/uclass-id.h | 1 + > include/fs_loader.h | 79 + > 5 files changed, 386 insertions(+) > create mode 100644 drivers/misc/fs_loader.c > create mode 100644 include/fs_loader.h I don't see a sandbox test for this. We need to add a test for every new uclass. Please let me know if you want some pointers to ideas. [..] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/6] doc: Add new doc for file system firmware loader driver model
Hi Tien,
On 6 July 2018 at 02:27, wrote:
> From: Tien Fong Chee
>
> Provide information about
>
> - overview of file system firmware loader driver model
> - describe storage device and partition in device tree source
> - describe fie system firmware loader API
>
> Signed-off-by: Tien Fong Chee
> ---
> doc/driver-model/fs_firmware_loader.txt | 133
>
> 1 file changed, 133 insertions(+)
> create mode 100644 doc/driver-model/fs_firmware_loader.txt
Reviewed-by: Simon Glass
A few comments below.
>
> diff --git a/doc/driver-model/fs_firmware_loader.txt
> b/doc/driver-model/fs_firmware_loader.txt
> new file mode 100644
> index 000..290915a
> --- /dev/null
> +++ b/doc/driver-model/fs_firmware_loader.txt
> @@ -0,0 +1,133 @@
> +# Copyright (C) 2018 Intel Corporation
> +#
> +# SPDX-License-Identifier:GPL-2.0
> +
> +Introduction
> +
> +
> +This is file system firmware loader for U-Boot framework, which has very
> close
> +to some Linux Firmware API. For the details of Linux Firmware API, you can
> refer
> +to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/index.html.
> +
> +File system firmware loader can be used to load whatever(firmware, image,
> +and binary) from the storage device in file system format into target
> location
> +such as memory, then consumer driver such as FPGA driver can program FPGA
> image
> +from the target location into FPGA.
> +
> +To enable firmware loader, CONFIG_FS_LOADER need to be set at
> +_defconfig such as "CONFIG_FS_LOADER=y".
> +
> +Firmware Loader API core features
> +-
> +
> +Firmware storage device described in device tree source
> +---
> + For passing data like storage device phandle and partition where the
> + firmware loading from to the firmware loader driver, those data could
> be
> + defined in fs-loader node as shown in below:
> +
> + Example for block device:
> + fs_loader0: fs-loader@0 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + phandlepart = < 1>;
I don't like this name much. How about
source-partition = < 1>;
or something like that?
> + };
> +
> + < 1> means block storage device pointer and its partition.
> +
> + Above example is a description for block storage, but for UBI storage
> + device, it can be described in FDT as shown in below:
> +
> + Example for ubi:
> + fs_loader1: fs-loader@1 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + mtdpart = "UBI",
> + ubivol = "ubi0";
> + };
> +
> + Then, firmware_loader property would be set with the path of fs_loader
> + node under /chosen node such as:
> + /{
> + chosen {
> + firmware_loader = _loader0;
> + };
> + };
> +
> + However, this driver is also designed to support U-boot environment
U-Boot
Please fix below also.
> + variables, so all these data from FDT can be overwritten
> + through the U-boot environment variable during run time.
> + For examples:
> + "storage_interface" - Storage interface, it can be "mmc", "usb",
> "sata"
> + or "ubi".
> + "fw_dev_part" - Block device number and its partition, it can be
> "0:1".
> + "fw_ubi_mtdpart" - UBI device mtd partition, it can be "UBI".
> + "fw_ubi_volume" - UBI volume, it can be "ubi0".
> +
> + When above environment variables are set, environment values would be
> + used instead of data from FDT.
> + The benefit of this design allows user to change storage attribute
> data
> + at run time through U-boot console and saving the setting as default
> + environment values in the storage for the next power cycle, so no
> + compilation is required for both driver and FDT.
> +
> +File system firmware Loader API
> +---
> +
> +int request_firmware_into_buf(struct device_platdata *plat,
> +const char *name,
> +void *buf, size_t size, u32 offset,
> +struct firmware **firmwarep)
> +
> +Load firmware into a previously allocated buffer
> +
> +Parameters:
> +
> +1. struct device_platdata *plat
> + Platform data such as storage and partition firmware loading from
> +
> +2. const char *name
> + name of firmware file
> +
> +3. void *buf
> + address of buffer to load firmware into
> +
> +4. size_t size
> + size of buffer
> +
> +5. u32 offset
> + offset of a file for start reading into buffer
> +
> +6. struct firmware **firmwarep
> + pointer to firmware image
> +
> +return:
Re: [U-Boot] [PATCH v4 5/6] doc: dtbinding: Add file system firmware loader binding document
On 6 July 2018 at 02:27, wrote: > From: Tien Fong Chee > > Add a document to describe file system firmware loader binding > information. > > Signed-off-by: Tien Fong Chee > --- > doc/device-tree-bindings/chosen.txt | 21 + > doc/device-tree-bindings/misc/fs_loader.txt | 48 > + > 2 files changed, 69 insertions(+) > create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt Reviewed-by: Simon Glass Apart from the naming of phandlepart, as I mentioned in the previous patch ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/6] block: Add a function to find block device descriptor
Hi Tien,
On 6 July 2018 at 02:26, wrote:
> From: Tien Fong Chee
>
> Add a function to find the block device descriptor of the parent
> device.
>
> Signed-off-by: Tien Fong Chee
> ---
> drivers/block/blk-uclass.c | 23 +++
> include/blk.h | 9 +
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> index 9e0c823..facf527 100644
> --- a/drivers/block/blk-uclass.c
> +++ b/drivers/block/blk-uclass.c
> @@ -132,6 +132,29 @@ struct blk_desc *blk_get_devnum_by_typename(const char
> *if_typename, int devnum)
> }
>
> /**
> + * blk_get_by_device() - Get the block device descriptor for the given device
> + * @dev: Instance of a storage device
> + *
> + * Return: With block device descriptor on success , NULL if there is no such
> + *block device.
> + */
> +struct blk_desc *blk_get_by_device(struct udevice *dev)
> +{
> + struct udevice *child_dev, *next;
> +
> + device_foreach_child_safe(child_dev, next, dev) {
> + if (device_get_uclass_id(child_dev) != UCLASS_BLK)
> + continue;
> +
> + return dev_get_uclass_platdata(child_dev);
> + }
> +
> + debug("%s: No block device found\n", __func__);
> +
> + return NULL;
> +}
Is this different from blk_get_from_parent() ?
[..]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 17/20] cmd: mtd: add 'mtd' command
On Wed, 11 Jul 2018 15:51:39 +0200
Miquel Raynal wrote:
> > > +
> > > + argc -= 3;
> > > + argv += 3;
> > > +
> > > + /* Do the parsing */
> > > + if (!strncmp(cmd, "read", 4) || !strncmp(cmd, "write", 5)) {
> > > + bool read, raw, woob;
> > > + uint *waddr = NULL;
> > > + u64 off, len;
> > > +
> > > + read = !strncmp(cmd, "read", 4);
> > > + raw = strstr(cmd, ".raw");
> > > + woob = strstr(cmd, ".oob");
> > > +
> > > + if (!read) {
> > > + if (argc < 1)
> > > + return CMD_RET_USAGE;
> > > +
> > > + waddr = map_sysmem(simple_strtoul(argv[0], NULL, 10),
> > > +0);
> > > + argc--;
> > > + argv++;
> > > + }
> > > +
> > > + off = argc > 0 ? simple_strtoul(argv[0], NULL, 10) : 0;
> > > + len = argc > 1 ? simple_strtoul(argv[1], NULL, 10) :
> > > + mtd->writesize + (woob ? mtd->oobsize : 0);
> > > +
> > > + if ((u32)off % mtd->writesize) {
> > > + printf("Section not page-aligned (0x%x)\n",
> > > +mtd->writesize);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (woob && (len != (mtd->writesize + mtd->oobsize))) {
> > > + printf("OOB operations are limited to single pages\n");
> > > + return -EINVAL;
> > > + }
> >
> > Is this a uboot limitation? I don't think you have such a limitation in
> > Linux.
>
> Kind of, only one single page write with OOB at a time is possible
> says a comment on mtd_oob_ops in mtd.h in Linux. Reads are actually not
> limited. But I really prefer to keep this limitation that simplifies _a
> lot_ the logic and is not really useful to a u-boot user I suppose.
It is useful when you write things in raw mode and the image you write
contains OOB (which in turn contains pre-generated ECC bytes). I know we
do such things on sunxi when writing the SPL.
>
> >
> > > +
> > > + if ((off + len) >= mtd->size) {
> >
> > That doesn't work when reading the last page of the MTD device with
> > woob = true. See how Linux handle that here [1]. BTW, why don't you let
> > mtdcore.c do these checks for you (that's also true for unaligned
> > accesses)?
>
> Because the relevant patch (and its fix :) ) has not been backported
> yet.
>
> And now I understand your voice in my ears "do it".
Hehe. So I guess I'll see this patch in your v2 :-).
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: Add bind/unbind commands to bind a device to a driver from the command line
On Fri, Jun 22, 2018 at 5:55 PM, Jean-Jacques Hiblot wrote: > In some cases it can be useful to be able to bind a device to a driver from > the command line. > The obvious example is for versatile devices such as USB gadget. > Another use case is when the devices are not yet ready at startup and > require some setup before the drivers are bound (ex: FPGA which bitsream is > fetched from a mass storage or ethernet) > > usage example: > > bind usb_dev_generic 0 usb_ether > unbind usb_dev_generic 0 usb_ether > or > unbind eth 1 Apart from having separate dm command, can't we add this as a part of 'usb reset' I'm thinking usb reset can show the all possible controllers shutdown and probe it again so-that gadget can show it like others. This is what I tried [1] [1] https://patchwork.ozlabs.org/patch/941597/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 10/20] spi: Extend the core to ease integration of SPI memory controllers
Hi Jagan, Jagan Teki wrote on Fri, 6 Jul 2018 17:02:22 +0530: > On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal > wrote: > > From: Boris Brezillon > > > > Some controllers are exposing high-level interfaces to access various > > kind of SPI memories. Unfortunately they do not fit in the current > > spi_controller model and usually have drivers placed in > > drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI > > memories in general. > > > > This is an attempt at defining a SPI memory interface which works for > > all kinds of SPI memories (NORs, NANDs, SRAMs). > > > > Signed-off-by: Boris Brezillon > > Signed-off-by: Miquel Raynal > > --- > > drivers/spi/Kconfig | 7 + > > drivers/spi/Makefile | 1 + > > drivers/spi/spi-mem.c | 500 > > ++ > > include/spi-mem.h | 258 ++ > > include/spi.h | 11 ++ > > 5 files changed, 777 insertions(+) > > create mode 100644 drivers/spi/spi-mem.c > > create mode 100644 include/spi-mem.h > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > > index 235a8c7d73..0ee371b2d9 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -15,6 +15,13 @@ config DM_SPI > > > > if DM_SPI > > > > +config SPI_MEM > > + bool "SPI memory extension" > > + help > > + Enable this option if you want to enable the SPI memory extension. > > + This extension is meant to simplify interaction with SPI memories > > + by providing an high-level interface to send memory-like commands. > > + > > config ALTERA_SPI > > bool "Altera SPI driver" > > help > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > > index 4b6000fd9a..982529a0e6 100644 > > --- a/drivers/spi/Makefile > > +++ b/drivers/spi/Makefile > > @@ -10,6 +10,7 @@ ifdef CONFIG_DM_SPI > > obj-y += spi-uclass.o > > obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o > > obj-$(CONFIG_SOFT_SPI) += soft_spi.o > > +obj-$(CONFIG_SPI_MEM) += spi-mem.o > > else > > obj-y += spi.o > > obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o > > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c > > new file mode 100644 > > index 00..1aabe56819 > > --- /dev/null > > +++ b/drivers/spi/spi-mem.c > > @@ -0,0 +1,500 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Copyright (C) 2018 Exceet Electronics GmbH > > + * Copyright (C) 2018 Bootlin > > + * > > + * Author: Boris Brezillon > > + */ > > + > > +#ifndef __UBOOT__ > > +#include > > +#include > > +#include "internals.h" > > +#else > > +#include > > +#include > > +#endif > > + > > +#ifndef __UBOOT__ > > I would like remove Linux stuff atleast on this file becuase it's > difficult for me to read or review the code and also driver/spi have > fully u-boot dm stuff. I know it's easy for Linux sync but for this we > can do manual sync what ever need. I'm on something what from Linux. I'm not sure this is a wise idea. And I don't understand how "driver/spi have fully u-boot dm stuff" is related in any manner to this request. But okay, if you commit to backport the changes/fixes on spi-mem from Linux yourself, let's remove them. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()
Dear Maxime, In message <20180711134735.vhhc7quuzcp42bo7@flea> you wrote: > > > If the feature is available, use cases will spring into mind. ... > > Right, but that would bring a much more significant rework as to how > the environments are handled than just the changes that are being > discussed here. At the moment, the environment can only be stored on > one device for each "types" (one raw MMC, one MTD partition, etc). The > redundancy allows you to duplicate it, but you won't be able to store > on just one instance of your choosing at the moment. I am aware of this. However, if we can pave the way for this to be added later at little or no additional cost, should we not try that? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only person who always got his work done by Friday was Robinson Crusoe. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/11/2018 8:48 AM, Marek Vasut wrote: > On 07/11/2018 03:49 PM, Jason Rush wrote: >> On 7/11/2018 3:55 AM, Marek Vasut wrote: >>> On 07/11/2018 05:11 AM, Jason Rush wrote: >>> [...] >>> However, if I press the HPS_RST push button on the SoCKit (which is connected to power on reset), occasionally U-Boot will lock up while booting. It always boots and operates correctly from the initial power on, but it almost always fails to boot after pressing the HPS_RST button. Usually after pressing the HPS_RST button, U-Boot makes it past the SPL, and hangs somewhere after the call to setup_reloc() in ./common/board_f.c. Once it hangs there, pressing the HPS_RST button again usually causes the SPL to hang while setting up the MMU (before my call to memset). Eventually the WDT kicks in, and it just keeps hanging up in the same place. Once it gets in this mode, the only way to recover it is by toggling power on the board. I spent a bunch of time today trying to track down where it was hanging, but I couldn't pin point anything. The MMU tables looked correct. The MMU registers looked good. I'm not sure the best way to debug what's going on. >>> Try triggering warm reset and cold reset via the reset register: >>> >>> mw 0xffd05004 1 >>> mw 0xffd05004 2 >>> >>> Does it hang in one case and not in the other ? >>> >> It hangs in both cases. >> >> I did find that if I do not metset the last 1MiB of DRAM with the cache >> on, >> both warm and cold resets work. >> >> I changed the ecc scrubbing to zero out the first 0x8000 bytes and the >> last >> 0x1 bytes before the MMU is setup and I enable dcache. Then with >> the dcache enabled, I zero out the rest of memory. The resets work in >> this >> case as well. So there seems to be some side effect of clearing out the >> relocate address space with the cache on. > Can you investigate ? > I'd be happy to investigate more, but I'm not really sure what my next step should be. Something appears to be happening differently when U-Boot relocates if the dcache is on. But don't know how to track it down. >>> IIRC I disabled cache after scrubbing. >> My mistake. I did disable the dcache after scrubbing too. The >> code is almost identical to the Arria10 code where after >> scrubbing it flushes the dcache, then turns it off. >> >> The weird reset problems happens if I scrub the area where >> u-boot relocates to with the dcache on, then turn dcache off. >> >> I tried to also tried turning the MMU off, but that didn't help. > Maybe there are some data used by the SPL there ? I think the SPL has > malloc area in RAM at some point. > I thought something similar, so I narrowed it down to clearing just from where U-Boot relocates to the end of DRAM. If I'm correct, that includes where U-Boot relocates and where the MMU tables are normally stored. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 17/20] cmd: mtd: add 'mtd' command
Hi Boris,
Boris Brezillon wrote on Wed, 6 Jun 2018
21:45:24 +0200:
> Hi Miquel,
>
> On Wed, 6 Jun 2018 17:30:37 +0200
> Miquel Raynal wrote:
>
> > There should not be a 'nand' command, a 'sf' command and certainly not
> > another 'spi-nand'. Write a 'mtd' command instead to manage all MTD
> > devices at once. This should be the preferred way to access any MTD
> > device.
>
> Just a few comments below, but overall, I'm really happy with this new
> set of commands and the fact that we'll soon be able to replace custom
> MTD accessors (nand, onenand, sf, cp.b+erase, ...) by these ones.
>
> >
> > Signed-off-by: Miquel Raynal
> > ---
> > cmd/Kconfig | 5 +
> > cmd/Makefile | 1 +
> > cmd/mtd.c| 280
> > +++
> > drivers/mtd/Makefile | 2 +-
> > 4 files changed, 287 insertions(+), 1 deletion(-)
> > create mode 100644 cmd/mtd.c
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 136836d146..6e9b629e1c 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -797,6 +797,11 @@ config CMD_MMC
> > help
> > MMC memory mapped support.
> >
> > +config CMD_MTD
> > + bool "mtd"
> > + help
> > + MTD commands support.
> > +
> > config CMD_NAND
> > bool "nand"
> > default y if NAND_SUNXI
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index 9a358e4801..e42db12e1d 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -88,6 +88,7 @@ obj-$(CONFIG_CMD_MISC) += misc.o
> > obj-$(CONFIG_CMD_MMC) += mmc.o
> > obj-$(CONFIG_CMD_MMC_SPI) += mmc_spi.o
> > obj-$(CONFIG_MP) += mp.o
> > +obj-$(CONFIG_CMD_MTD) += mtd.o
> > obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
> > obj-$(CONFIG_CMD_NAND) += nand.o
> > obj-$(CONFIG_CMD_NET) += net.o
> > diff --git a/cmd/mtd.c b/cmd/mtd.c
> > new file mode 100644
> > index 00..fe48378bd0
> > --- /dev/null
> > +++ b/cmd/mtd.c
> > @@ -0,0 +1,280 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * mtd.c
> > + *
> > + * Generic command to handle basic operations on any memory device.
> > + *
> > + * Copyright: Bootlin, 2018
> > + * Author: Miquèl Raynal
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static void mtd_dump_buf(u8 *buf, uint len)
> > +{
> > + int i, j;
> > +
> > + for (i = 0; i < len; ) {
> > + printf("0x%08x:\t", i);
> > + for (j = 0; j < 8; j++)
> > + printf("%02x ", buf[i + j]);
> > + printf(" ");
> > + i += 8;
> > + for (j = 0; j < 8; j++)
> > + printf("%02x ", buf[i + j]);
> > + printf("\n");
> > + i += 8;
> > + }
> > +}
> > +
> > +static void mtd_show_device(struct mtd_info *mtd)
> > +{
> > + printf("* %s", mtd->name);
> > + if (mtd->dev)
> > + printf(" [device: %s] [parent: %s] [driver: %s]",
> > + mtd->dev->name, mtd->dev->parent->name,
> > + mtd->dev->driver->name);
> > +
> > + printf("\n");
> > +}
> > +
> > +static int do_mtd_list(void)
> > +{
> > + struct mtd_info *mtd;
> > + struct udevice *dev;
> > + int dm_idx = 0, idx = 0;
> > +
> > + /* Ensure all devices compliants with U-Boot driver model are probed */
> > + while (!uclass_find_device(UCLASS_MTD, dm_idx, ) && dev) {
> > + mtd_probe(dev);
> > + dm_idx++;
> > + }
> > +
> > + printf("MTD devices list (%d DM compliant):\n", dm_idx);
>
> Do we really want to say how many of them are exported by DM compliant
> drivers? I mean, the user doesn't care about that. If you want to force
> people to convert their drivers, we should probably complain at MTD
> device registration time when the mtd_info struct is not backed by an
> udevice.
It was more like a small debug value but I don't really care about it.
Parenthesis removed.
>
> > +
> > + mtd_for_each_device(mtd) {
> > + mtd_show_device(mtd);
> > + idx++;
> > + }
> > +
> > + if (!idx)
> > + printf("No MTD device found\n");
> > +
> > + return 0;
> > +}
> > +
> > +static int do_mtd_read_write(struct mtd_info *mtd, bool read, uint *waddr,
> > +bool raw, bool woob, u64 from, u64 len)
>
> s/do_mtd_read_write/do_mtd_io/ ?
+1 for the artistic name :) -> renamed
> And why not passing an mtd_oob_ops
> object directly? That would reduce the number of parameters you pass to
> this function.
Good point actually. While rewriting the function I figured out there
was no "reusable code" nor any "logicial split" with this do_mtd_io()
helper so I just moved the code from it into the main do_mtd(). If you
find it unclear please tell me where
>
> > +{
> > + u32 buf_len = woob ? mtd->writesize + mtd->oobsize :
> > +ROUND(len, mtd->writesize);
> > + u8 *buf = malloc(buf_len);
>
> It's probably worth a comment explaining why you allocate
Re: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()
On Wed, Jul 11, 2018 at 12:44:23PM +0200, Nicholas wrote: > > > > Maybe a solution could be to have an env_save() function which > > > > acts in a similar way as proposed in my patch and an > > > > env_save_prio() function, which acts like the env_load() > > > > i.e. looking for the best working location instead of relying > > > > on what has been stored into gd-> env_load_location. > > > > > > I don't really see a use-case for overriding wherever the > > > environment at the user-level actually. At the board level, for > > > redundancy or transition, yes, definitely, but we can already do > > > that. > > > > Well, the use case I saw was that I wanted to test redundant > > environment storage. I admit this is not an end user use case but > > a developer use case, so I guess you're right. > > > > So after fixing this endless loops I see two questions: - to which > > environment do we store if the one in 'env_load_location' fails > > to store? > > Good question. My opinion is that it strongly depends on what we want > to achieve with the implementation: do we want 1) to keep the > consistency between load and save, or we want 2) to guarantee to be > able to load/save from at least one location? > > If 1) then a failure on env_save() simply fails and doesn't store > anything. In other words we are multi-env when loading but single-env > when storing. We are actually binding env_save() to the last > env_load()'s result. > > If 2) then a failure on env_save() will try all the available locations > but we are open to misalignments. Here we are full multi-env since > env_save() and env_load() are not bound together. In that case, we don't want to store to a lower priority, but to a higher one. Otherwise, the environment will be saved just fine, but will not be read next time, which will be very confusing to the user. And with a higher priority, you might end up overwriting something you weren't expecting to overwrite, so I'd vote 1. -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 07/11/2018 03:49 PM, Jason Rush wrote: > On 7/11/2018 3:55 AM, Marek Vasut wrote: >> On 07/11/2018 05:11 AM, Jason Rush wrote: >> [...] >> >>> However, if I press the HPS_RST push button on the SoCKit (which is >>> connected >>> to power on reset), occasionally U-Boot will lock up while booting. It >>> always >>> boots and operates correctly from the initial power on, but it almost >>> always >>> fails to boot after pressing the HPS_RST button. >>> >>> Usually after pressing the HPS_RST button, U-Boot makes it past the >>> SPL, and >>> hangs somewhere after the call to setup_reloc() in ./common/board_f.c. >>> Once >>> it hangs there, pressing the HPS_RST button again usually causes the >>> SPL to >>> hang while setting up the MMU (before my call to memset). Eventually >>> the >>> WDT kicks in, and it just keeps hanging up in the same place. Once it >>> gets in >>> this mode, the only way to recover it is by toggling power on the board. >>> >>> I spent a bunch of time today trying to track down where it was >>> hanging, but >>> I couldn't pin point anything. The MMU tables looked correct. The MMU >>> registers looked good. I'm not sure the best way to debug what's going >>> on. >> Try triggering warm reset and cold reset via the reset register: >> >> mw 0xffd05004 1 >> mw 0xffd05004 2 >> >> Does it hang in one case and not in the other ? >> > It hangs in both cases. > > I did find that if I do not metset the last 1MiB of DRAM with the cache > on, > both warm and cold resets work. > > I changed the ecc scrubbing to zero out the first 0x8000 bytes and the > last > 0x1 bytes before the MMU is setup and I enable dcache. Then with > the dcache enabled, I zero out the rest of memory. The resets work in > this > case as well. So there seems to be some side effect of clearing out the > relocate address space with the cache on. Can you investigate ? >>> I'd be happy to investigate more, but I'm not really sure what >>> my next step should be. >>> >>> Something appears to be happening differently when U-Boot >>> relocates if the dcache is on. But don't know how to track it >>> down. >> IIRC I disabled cache after scrubbing. > > My mistake. I did disable the dcache after scrubbing too. The > code is almost identical to the Arria10 code where after > scrubbing it flushes the dcache, then turns it off. > > The weird reset problems happens if I scrub the area where > u-boot relocates to with the dcache on, then turn dcache off. > > I tried to also tried turning the MMU off, but that didn't help. Maybe there are some data used by the SPL there ? I think the SPL has malloc area in RAM at some point. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
