Re: EFI breaks USB dual port detection - our observations
On Tue, Jul 18, 2023 at 3:13 PM Heinrich Schuchardt wrote: > > > Am 18. Juli 2023 20:37:04 MESZ schrieb Suniel Mahesh < > su...@amarulasolutions.com>: > >Hi, > > > >I am testing the USB infrastructure on a Rockchip RK3328 based > >roc-rk3328-cc target. > > > >The USB tree on the device is as follows: > > > >=> usb tree > >USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > u-boot EHCI Host Controller > > > > 1 Hub (12 Mb/s, 0mA) > > U-Boot Root Hub (OHCI) > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > 1 Hub (480 Mb/s, 0mA) > > U-Boot Root Hub (DWC2) > > > >For some reason I am unable to detect storage device on DWC2 when two USB > >drives > >are simultaneously connected on EHCI and DWC2. Though it shows 2 storage > >devices > >when i do a "usb start/reset" and it gives usb_mass_storage.lun0 failed > >message as > >shown below. > > On which U-Boot version are you? > This is replicated on v2023.07. > > Cf. > https://github.com/trini/u-boot/commit/180b7118bed8433f9cfe4b5ad62c6b0d901924f5 > > Best regards > > Heinrich > > > > > > >=> usb start > >starting USB... > >Bus usb@ff5c: USB EHCI 1.00 > >Bus usb@ff5d: USB OHCI 1.0 > >Bus usb@ff60: generic_phy_get_bulk : no phys property > >Register 2000140 NbrPorts 2 > >Starting the controller > >USB XHCI 1.10 > >Bus usb@ff58: USB DWC2 > >scanning bus usb@ff5c for devices... > >2 USB Device(s) found > >scanning bus usb@ff5d for devices... 1 USB Device(s) found > >scanning bus usb@ff60 for devices... 1 USB Device(s) found > >scanning bus usb@ff58 for devices... > >Adding disk for usb_mass_storage.lun0 failed > >(err=-9223372036854775788/0x8014) > >device 'usb_mass_storage.lun0' failed to unbind > >1 USB Device(s) found > >device 'usb_mass_storage.lun0' failed to unbind > > scanning usb for storage devices... 2 Storage Device(s) found > > > >=> usb tree > >USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > | u-boot EHCI Host Controller > > | > > +-2 Mass Storage (480 Mb/s, 224mA) > > SanDisk Dual Drive 040130e3ee554b7078843f4eb331646 > > > > 1 Hub (12 Mb/s, 0mA) > > U-Boot Root Hub > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > 1 Hub (480 Mb/s, 0mA) > > U-Boot Root Hub > > > >call trace: (detailed log: > >https://gist.github.com/sunielmahesh/10088ea7b536cc9898ef787d9db43721) > > > >efi_install_multiple_protocol_interfaces_int > >device path > > >/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0) > >09576e91-6d3f-11d2-8e39-00a0c969723b, fcf1bae8, > >fcf1bae0efi_locate_device_path: ret = EFI_SUCCESS > >efi_install_multiple_protocol_interfaces_int: ret=0, dp->type:7f > >Path > > >/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0) > >already installed > >install failed 8014 > > > >However, an interesting observation is that if i disable > CONFIG_EFI_LOADER, > >then I am able to detect the storage devices > >without any usb_mass_storage.lun0 failed message: > > > >=> usb reset > >resetting USB... > >Bus usb@ff5c: USB EHCI 1.00 > >Bus usb@ff5d: USB OHCI 1.0 > >Bus usb@ff60: generic_phy_get_bulk : no phys property > >Register 2000140 NbrPorts 2 > >Starting the controller > >USB XHCI 1.10 > >Bus usb@ff58: USB DWC2 > >scanning bus usb@ff5c for devices... 2 USB Device(s) found > >scanning bus usb@ff5d for devices... 1 USB Device(s) found > >scanning bus usb@ff60 for devices... 1 USB Device(s) found > >scanning bus usb@ff58 for devices... 2 USB Device(s) found > > scanning usb for storage devices... 2 Storage Device(s) found > >=> usb tree > >USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > | u-boot EHCI Host Controller > > | > > +-2 Mass Storage (480 Mb/s, 224mA) > > SanDisk Dual Drive 040130e3ee554b7078843f4eb331646 > > > > 1 Hub (12 Mb/s, 0mA) > > U-Boot Root Hub > > > > 1 Hub (5 Gb/s, 0mA) > > U-Boot XHCI Host Controller > > > > 1 Hub (480 Mb/s, 0mA) > > | U-Boot Root Hub > > | > > +-2 Mass Storage (480 Mb/s, 224mA) > > SanDisk Dual Drive 04019c9b2e1a58f24ee318c3c123aa5 > > > >Please share you thoughts. > > > >Thanks and Regards >
bootstd regression from distro_bootcmd for removable EFI boot and weird return codes for fs
Hi, I switch to bootstd and I am experiencing an issue with bootstd not detected EFI bootable file in /EFI/BOOT/BOOTAA64.EFI in certain image, buildroot specifically. The same setup works fine with distro_bootcmd. I have attached the logs. I have tried the following: 1) Directory and filename case upper and lower 2) FAT32 and FAT16 filesystem 3) Changing the size of the filesystem I noticed some particular weirdness with u-boot's return code for functions dealing with fs_exists that might be related. 1) FAT/FAT32 driver uses fs_ls_generic. When you do `ls mmc 1 /filename`, it returns 1 if the file exists and returns 1 when the file doesn't exist. 2) This issue follows fs_exists. Is this a bug or intended behavior? Best, Da bootstd.log Description: Binary data
Re: bootstd regression from distro_bootcmd for removable EFI boot and weird return codes for fs
t_e 30 script media mmc e mmc@72000.bootdev.part_e 31 efi media mmc f mmc@72000.bootdev.part_f 32 extlinux media mmc f mmc@72000.bootdev.part_f 33 script media mmc f mmc@72000.bootdev.part_f 34 efi media mmc 10 mmc@72000.bootdev.part_10 35 extlinux media mmc 10 mmc@72000.bootdev.part_10 36 script media mmc 10 mmc@72000.bootdev.part_10 37 efi media mmc 11 mmc@72000.bootdev.part_11 38 extlinux media mmc 11 mmc@72000.bootdev.part_11 39 script media mmc 11 mmc@72000.bootdev.part_11 3a efi media mmc 12 mmc@72000.bootdev.part_12 3b extlinux media mmc 12 mmc@72000.bootdev.part_12 3c script media mmc 12 mmc@72000.bootdev.part_12 3d efi media mmc 13 mmc@72000.bootdev.part_13 3e extlinux media mmc 13 mmc@72000.bootdev.part_13 3f script media mmc 13 mmc@72000.bootdev.part_13 40 efi media mmc 14 mmc@72000.bootdev.part_14 41 extlinux media mmc 14 mmc@72000.bootdev.part_14 42 script media mmc 14 mmc@72000.bootdev.part_14 43 efi media mmc 15 mmc@72000.bootdev.part_15 44 extlinux media mmc 15 mmc@72000.bootdev.part_15 45 script media mmc 15 mmc@72000.bootdev.part_15 46 efi media mmc 16 mmc@72000.bootdev.part_16 47 extlinux media mmc 16 mmc@72000.bootdev.part_16 48 script media mmc 16 mmc@72000.bootdev.part_16 49 efi media mmc 17 mmc@72000.bootdev.part_17 4a extlinux media mmc 17 mmc@72000.bootdev.part_17 4b script media mmc 17 mmc@72000.bootdev.part_17 4c efi media mmc 18 mmc@72000.bootdev.part_18 4d extlinux media mmc 18 mmc@72000.bootdev.part_18 4e script media mmc 18 mmc@72000.bootdev.part_18 4f efi media mmc 19 mmc@72000.bootdev.part_19 50 extlinux media mmc 19 mmc@72000.bootdev.part_19 51 script media mmc 19 mmc@72000.bootdev.part_19 52 efi media mmc 1a mmc@72000.bootdev.part_1a 53 extlinux media mmc 1a mmc@72000.bootdev.part_1a 54 script media mmc 1a mmc@72000.bootdev.part_1a 55 efi media mmc 1b mmc@72000.bootdev.part_1b 56 extlinux media mmc 1b mmc@72000.bootdev.part_1b 57 script media mmc 1b mmc@72000.bootdev.part_1b 58 efi media mmc 1c mmc@72000.bootdev.part_1c 59 extlinux media mmc 1c mmc@72000.bootdev.part_1c 5a script media mmc 1c mmc@72000.bootdev.part_1c 5b efi media mmc 1d mmc@72000.bootdev.part_1d 5c extlinux media mmc 1d mmc@72000.bootdev.part_1d 5d script media mmc 1d mmc@72000.bootdev.part_1d No more bootdevs --- --- -- (94 bootflows, 0 valid) ``` ls return 1 ``` => ls mmc 1 /efi/boot ./ ../ 51806720 BOOTAA64.EFI 1 file(s), 2 dir(s) => echo $? 0 => ls mmc 1 /efi/boot/bootaa64.efi => echo $? 1 => ls mmc 1 /EFI/boot/BOOTAA64.EFI => echo $? 1 => ls mmc 1 / EFI/ 0 file(s), 1 dir(s) => ls mmc 1 /EFI/ ./ ../ BOOT/ 0 file(s), 3 dir(s) => ls mmc 1 /EFI/BOOT/BOOTAA64.EFI => echo $? 1 => ls mmc 1 /EFI/BOOT ./ ../ 51806720 BOOTAA64.EFI 1 file(s), 2 dir(s) => ls mmc 1 /EFI/BOOT/nonexist => echo $? 1 ``` On Mon, Jul 24, 2023 at 11:35 AM Da Xue wrote: > > Hi, > > I switch to bootstd and I am experiencing an issue with bootstd not > detected EFI bootable file in /EFI/BOOT/BOOTAA64.EFI in certain image, > buildroot specifically. The same setup works fine with distro_bootcmd. > I have attached the logs. I have tried the following: > > 1) Directory and filename case upper and lower > 2) FAT32 and FAT16 filesystem > 3) Changing the size of the filesystem > > I noticed some particular weirdness with u-boot's return code for > functions dealing with fs_exists that might be related. > > 1) FAT/FAT32 driver uses fs_ls_generic. When you do `ls mmc 1 > /filename`, it returns 1 if the file exists and returns 1 when the > file doesn't exist. > 2) This issue follows fs_exists. Is this a bug or intended behavior? > > Best, > Da
Re: bootstd regression from distro_bootcmd for removable EFI boot and weird return codes for fs
On Mon, Jul 24, 2023 at 11:48 AM Da Xue wrote:
>
> I forgot to attach some additional details:
>
> ```
> sudo fdisk -l /dev/sda
> Disk /dev/sda: 58.24 GiB, 62534975488 bytes, 122138624 sectors
> Disk model: STORAGE DEVICE
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x
>
> Device Boot StartEnd Sectors Size Id Type
> /dev/sda1 * 2048 524287 522240 255M ef EFI (FAT-12/16/32)
> ```
>
> The image was generated via buildroot using genimage:
>
> ```
> image boot.vfat {
> vfat {
> file EFI/BOOT/BOOTAA64.EFI {
> image = "Image"
> }
> extraargs = "-F32" # tried with and without this flag,
> same issue.
> }
> size = 255M
> }
>
> image sdcard.img {
> hdimage {
> }
> partition bootloader {
> in-partition-table = false
> offset = 512
> image = "u-boot.bin"
> }
> partition rootfs {
> partition-type = 0xEF
> bootable = "true"
> image = "boot.vfat"
> offset = 1M
> }
> }
> ```
>
> bootflow -la without the debug messages:
>
> ```
> => bootflow scan -la
> Scanning for bootflows in all bootdevs
> Seq Method State UclassPart Name Filename
> --- --- --
>
> Scanning global bootmeth 'efi_mgr':
> 0 efi_mgr base(none) 0
> Scanning bootdev 'mmc@74000.bootdev':
> 1 efi media mmc 0 mmc@74000.bootdev.whole
> 2 extlinux media mmc 0 mmc@74000.bootdev.whole
> 3 script media mmc 0 mmc@74000.bootdev.whole
> Scanning bootdev 'mmc@72000.bootdev':
> 4 efi media mmc 0 mmc@72000.bootdev.whole
> 5 extlinux media mmc 0 mmc@72000.bootdev.whole
> 6 script media mmc 0 mmc@72000.bootdev.whole
> 7 efi filemmc 1 mmc@72000.bootdev.part_1
> efi/boot/bootaa64.efi
> 8 extlinux fs mmc 1 mmc@72000.bootdev.part_1
> /boot/extlinux/extlinux.conf
> 9 script fs mmc 1 mmc@72000.bootdev.part_1
> /boot/boot.scr
> a efi media mmc 2 mmc@72000.bootdev.part_2
> b extlinux media mmc 2 mmc@72000.bootdev.part_2
> c script media mmc 2 mmc@72000.bootdev.part_2
> d efi media mmc 3 mmc@72000.bootdev.part_3
> e extlinux media mmc 3 mmc@72000.bootdev.part_3
> f script media mmc 3 mmc@72000.bootdev.part_3
> 10 efi media mmc 4 mmc@72000.bootdev.part_4
> 11 extlinux media mmc 4 mmc@72000.bootdev.part_4
> 12 script media mmc 4 mmc@72000.bootdev.part_4
> 13 efi media mmc 5 mmc@72000.bootdev.part_5
> 14 extlinux media mmc 5 mmc@72000.bootdev.part_5
> 15 script media mmc 5 mmc@72000.bootdev.part_5
> 16 efi media mmc 6 mmc@72000.bootdev.part_6
> 17 extlinux media mmc 6 mmc@72000.bootdev.part_6
> 18 script media mmc 6 mmc@72000.bootdev.part_6
> 19 efi media mmc 7 mmc@72000.bootdev.part_7
> 1a extlinux media mmc 7 mmc@72000.bootdev.part_7
> 1b script media mmc 7 mmc@72000.bootdev.part_7
> 1c efi media mmc 8 mmc@72000.bootdev.part_8
> 1d extlinux media mmc 8 mmc@72000.bootdev.part_8
> 1e script media mmc 8 mmc@72000.bootdev.part_8
> 1f efi media mmc 9 mmc@72000.bootdev.part_9
> 20 extlinux media mmc 9 mmc@72000.bootdev.part_9
> 21 script media mmc 9 mmc@72000.bootdev.part_9
> 22 efi media mmc a mmc@72000.bootdev.part_a
> 23 extlinux media mmc a mmc@72000.bootdev.part_a
> 24 script media mmc a mmc@72000.bootdev.part_a
> 25 efi media mmc b mmc@72000.bootdev.part_b
> 26 extlinux media mmc b mmc@72000.bootdev.part_b
> 27 script media mmc b mmc@72000.bootdev.part_b
> 28
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut wrote: > > On 10/13/23 06:53, Venkatesh Yadav Abbarapu wrote: > > The xhci host controller driver trying to queue the URB's and it is > > getting halted at the endpoint, thereby hitting the BUG_ON's. > > Mostly these kind of random issues are seen on faulty boards. > > Removing these BUG_ON's from the U-Boot xhci code, as in Linux kernel > > xhci code BUG_ON/BUG's are removed entirely. > > Please also note, that BUG_ON() is not recommended any more in the Linux > > kernel. > > Similar issue has been observed on TI AM437x board and they created a patch > > in Linux kernel as below > > https://patches.linaro.org/project/linux-usb/patch/1390250711-25840-1-git-send-email-ba...@ti.com/ > > > > Signed-off-by: Venkatesh Yadav Abbarapu > > I already explained to Xilinx how to sync the driver with Linux and why > this is needed to move forward, multiple times, and even provided a > script which does most of the work automatically, since it is basically > automated process. Xilinx did not even bother to test the script and > provide any feedback. > > Until that happens, this patch is rejected. This patch also causes all of the USB devices on certain platforms to not be detected: scanning bus usb@c900 for devices... Device not responding to set address. USB device not accepting new address (error=8000)
Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image
On Wed, Apr 5, 2023 at 2:39 PM Simon Glass wrote: > > Hi Christian, > > On Mon, 3 Apr 2023 at 20:10, Christian Hewitt > wrote: > > > > > On 2 Apr 2023, at 6:41 am, Simon Glass wrote: > > > > > > Hi Mark, > > > > > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis > > > wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Sun, 2 Apr 2023 06:54:57 +1200 > > > > > > > > > > The Odroid-C2 is quite a complicated image with many steps. It is an > > > > > ideal > > > > > example for how Binman can be used. > > > > > > > > You say Odroid-C2, but the patches seem to address the Odroid-C4... > > > > > > Ah, yes. The difference seems to be an Amlogic S905 on the C2 and an > > > S902X3 on the C4. I wonder if that affects the image makeup? > > > > There are currently four different signing recipes that depend on the > > board family that you are building for: > > > > - GXBB > > - GXL/GXM > > - G12A/SM1 > > - G12B > > > > The G12A/SM1 and G12B recipes are identical except for a different > > signing binary used. The latest Amlogic boards (S905X4, T7, etc.) > > also have incremental changes, but none are currently supported in > > Linux or u-boot. > > > > One of the challenges for binman will be the signing tools. Currently > > this patchset depends upon Amlogic binaries. Apart from them being > > closed-source and thus undesirable, they are also x86_64 only and > > there are quite a few users (and at least one major distro) needing > > to build on arm64 hardware. > > > > There is an open-source tool called gxlimg which supports GXL and newer > > boards. IMHO it would make a lot of sense for u-boot to absorb the > > functionality of gxlimg (and extend support backwards to GXBB) as this > > would remove the dependency on Amlogic binaries and allow u-boot build > > and binman signing to be done anywhere. > > > > https://github.com/repk/gxlimg gxlimg also does not have the full featureset of the Amlogic signer. The most important to me being lz4 compression. I'm still trying to get support from Amlogic for open source ATF at least for GXX but that has numerous hurdles to overcome and more hurdles for future designs. > > Fair enough, but another option would be to allow 'binman tool -f > gxlimg' to work, which should be easy. Then we can make use of the > existing C code, using binary tools for the unsupported ones. > > > > > > The patch is for testing by Christian, who I hope can help get this > > > landed for all the Amlogic boards. > > > > I will try to find the time to test this, but it’s not something I > > could do more with (as only supporting 1/4 of the board families > > that I need to build for, bu I do appreciate it’s a POC). > > Yes, it's a start. > > > > > In case you’re not aware, Makefile based signing is implemented in > > the amlogic-boot-fip repo that I’m currently tooled around: > > > > https://github.com/LibreELEC/amlogic-boot-fip The issue with the boot fips is that they control too many things (CPU freq, DDR freq, M3 control code, and more) to make it universal. > > > > This is the “competition” so to speak. It’s quite simple and widely > > used by most of the Amlogic supporting distros right now. > > Well at least that provides the recipes. > > Regards, > Simon > > ___ > linux-amlogic mailing list > linux-amlo...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic
Re: [RFT PATCH 0/2] mmc: meson-gx: improve MMC reliabilty
On Thu, Nov 23, 2023 at 8:54 AM Neil Armstrong wrote: > > On 15/09/2023 18:01, Jerome Brunet wrote: > > Amlogic MMC on the GX (and later) SoCs has been problematic for years, > > especially with u-boot. > > > > Linux has been fairly stable for a few years. It is using a fixed phase > > setting with Core = 180, Tx = 0 and Rx = 0 (the latter cannot be set > > starting from the v3 MMC IPs) > > > > Still the results were not good with those settings with u-boot, on some > > sm1 based platforms. U-boot then started using a 270 core phase for sm1 > > only. This worked for most sm1 platforms but problems persist on others. > > > > The proposal with this patchset is to use 270 for the ID phase, 180 > > otherwise. This works well on the platforms I have tested (Libretech's > > boards and VIM3L) > > > > It would be great if others could test this and report whether this work > > for them or not. > > > > If the results are good, this might be ported to Linux as well (... but the > > situation is less critical there) > > > > Jerome Brunet (2): > >mmc: meson-gx: clean up and align on Linux settings > >mmc: meson-gx: set 270 core phase during the identification > > > > drivers/mmc/meson_gx_mmc.c | 50 ++ > > drivers/mmc/meson_gx_mmc.h | 9 +-- > > 2 files changed, 31 insertions(+), 28 deletions(-) > > > > I got a regression with this patchset on the BPI M5 (SM1) SDCard, u-boot > pytest results: > - https://gitlab.com/amlogic-foss/amlogic-u-boot-autotest/-/jobs/5603936884 > - full HTML log: > https://amlogic-foss.gitlab.io/-/amlogic-u-boot-autotest/-/jobs/5603936884/artifacts/test-log.html > Same device but without the patch: > - https://gitlab.com/amlogic-foss/amlogic-u-boot-autotest/-/jobs/5601899556 > - full HTML log: > https://amlogic-foss.gitlab.io/-/amlogic-u-boot-autotest/-/jobs/5601899556/artifacts/test-log.html > Same branch but on A311D gives expected results: > - https://gitlab.com/amlogic-foss/amlogic-u-boot-autotest/-/jobs/5603932746 > - full HTML log: > https://amlogic-foss.gitlab.io/-/amlogic-u-boot-autotest/-/jobs/5603932746/artifacts/test-log.html > > > eMMC devices gets 26MHz speed instead of 52MHz, and SD reads and writes gives > random errors: > > => mmc info > Device: mmc@ffe07000 > Manufacturer ID: 15 > OEM: 0 > Name: AJTD4R > Bus Speed: 2600 > Mode: MMC High Speed (26MHz) > Rd Block Len: 512 > MMC version 5.1 > High Capacity: Yes > Capacity: 4 MiB > Bus Width: 8-bit > Erase Group Size: 512 KiB > HC WP Group Size: 8 MiB > User Capacity: 14.6 GiB WRREL > Boot Capacity: 4 MiB ENH > RPMB Capacity: 4 MiB ENH > Boot area 0 is not write protected > Boot area 1 is not write protected > > => mmc dev 0 > ** fs_devread read error - block > switch to partitions #0, OK > mmc0 is current device > => mmc read 0x0020 0 1000 > MMC read: dev # 0, block # 0, count 4096 ... 0 blocks read: ERROR > => mmc write 0x0020 20 3e8 > MMC write: dev # 0, block # 2097152, count 1000 ... 0 blocks written: ERROR > > > I ran the test twice to be sure. I experienced some issues with certain SD cards as well on AML-S905D3-CC-V02. I have a bunch of SD cards and will go through testing them later this week. => mmc dev 1 switch to partitions #0, OK mmc1 is current device => mmc info Device: mmc@ffe05000 Manufacturer ID: df OEM: 2104 Name: SDBus Speed: 2500 Mode: MMC legacy Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 58.2 GiB Bus Width: 1-bit Erase Group Size: 512 Bytes => mmc read $kernel_addr_r 0 1 MMC read: dev # 1, block # 0, count 65536 ... 0 blocks read: ERROR > > Neil > > > -=-=-=-=-=-=-=-=-=-=-=- > Groups.io Links: You receive all messages sent to this group. > View/Reply Online (#1889): https://groups.io/g/u-boot-amlogic/message/1889 > Mute This Topic: https://groups.io/mt/102766907/1922544 > Group Owner: u-boot-amlogic+ow...@groups.io > Unsubscribe: > https://groups.io/g/u-boot-amlogic/leave/4137477/1922544/1183329822/xyzzy > [d...@lessconfused.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Re: [PATCH 13/15] rockchip: rk3328: Add support to build bootable SPI image
On Wed, Feb 7, 2024 at 10:53 PM Dragan Simic wrote:
>
> Hello Jonas,
>
> On 2024-02-07 01:02, Jonas Karlman wrote:
> > Similar to RK35xx the BootRom in RK3328 can read all data and look for
> > idbloader at 0x8000, same as on SD and eMMC.
> >
> > Use the rksd format and modify the mkimage offset to generate a
> > bootable
> > u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.
> >
> > Signed-off-by: Jonas Karlman
>
> Could you, please, clarify a bit why the "rkspi" format isn't used
> instead of "rksd"?
"The SPI code has a bug that means that the 2 KiB blocks in which the
bootloader is loaded have a stride of 4KiB, leaving the 2KiB inbetween
as unused padding."
RK3399 has the 2K SPI bug and necessitated the rkspi format. RK3328
came after RK3399 and resolved this bug so the SPI and MMC formats are
now the same.
I verified on a ROC-RK3328-CC-V2.
>
> > ---
> > arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
> > arch/arm/mach-rockchip/rk3328/rk3328.c | 1 +
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3328-u-boot.dtsi
> > b/arch/arm/dts/rk3328-u-boot.dtsi
> > index b90d78878d77..2a5dca97dd4b 100644
> > --- a/arch/arm/dts/rk3328-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3328-u-boot.dtsi
> > @@ -120,3 +120,14 @@
> > &usb20_otg {
> > hnp-srp-disable;
> > };
> > +
> > +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
> > +&binman {
> > + simple-bin-spi {
> > + mkimage {
> > + args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> > + offset = <0x8000>;
> > + };
> > + };
> > +};
> > +#endif
> > diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
> > b/arch/arm/mach-rockchip/rk3328/rk3328.c
> > index b591d38fe412..b82b209de9e2 100644
> > --- a/arch/arm/mach-rockchip/rk3328/rk3328.c
> > +++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
> > @@ -36,6 +36,7 @@
> >
> > const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> > [BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
> > + [BROM_BOOTSOURCE_SPINOR] = "/spi@ff19/flash@0",
> > [BROM_BOOTSOURCE_SD] = "/mmc@ff50",
> > };
Re: [U-Boot] [PATCH v2 13/18] autoboot: Tidy up use of menukey
Hi Simon,
The Kconfig doesn't match the common/autoboot.c. Kconfig is using
AUTOBOOT_USE_MENUKEY and common/autoboot.c is CONFIG_USE_AUTOBOOT_MENUKEY.
Best,
Da
On Sat, Jul 20, 2019 at 11:56 PM Simon Glass wrote:
> Move the variable to the top of the file and adjust the code which uses it
> to use if() rather than #ifdef, to make it easier to read.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> common/autoboot.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/common/autoboot.c b/common/autoboot.c
> index ad189a8ba2..9752470873 100644
> --- a/common/autoboot.c
> +++ b/common/autoboot.c
> @@ -28,6 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
>
> /* Stored value of bootdelay, used by autoboot_command() */
> static int stored_bootdelay;
> +static int menukey;
>
> #ifdef CONFIG_AUTOBOOT_ENCRYPTION
> #define AUTOBOOT_STOP_STR_SHA256 CONFIG_AUTOBOOT_STOP_STR_SHA256
> @@ -35,6 +36,12 @@ static int stored_bootdelay;
> #define AUTOBOOT_STOP_STR_SHA256 ""
> #endif
>
> +#ifdef CONFIG_USE_AUTOBOOT_MENUKEY
> +#define AUTOBOOT_MENUKEY CONFIG_USE_AUTOBOOT_MENUKEY
> +#else
> +#define AUTOBOOT_MENUKEY 0
> +#endif
> +
> /*
> * Use a "constant-length" time compare function for this
> * hash compare:
> @@ -224,10 +231,6 @@ static int abortboot_key_sequence(int bootdelay)
> return abort;
> }
>
> -#ifdef CONFIG_USE_AUTOBOOT_MENUKEY
> -static int menukey;
> -#endif
> -
> static int abortboot_single_key(int bootdelay)
> {
> int abort = 0;
> @@ -250,13 +253,13 @@ static int abortboot_single_key(int bootdelay)
> ts = get_timer(0);
> do {
> if (tstc()) { /* we got a key press */
> + int key;
> +
> abort = 1; /* don't auto boot */
> bootdelay = 0; /* no more delay*/
> -# ifdef CONFIG_USE_AUTOBOOT_MENUKEY
> - menukey = getc();
> -# else
> - (void) getc(); /* consume input*/
> -# endif
> + key = getc(); /* consume input */
> + if
> (IS_ENABLED(CONFIG_USE_AUTOBOOT_MENUKEY))
> + menukey = key;
> break;
> }
> udelay(1);
> @@ -358,11 +361,10 @@ void autoboot_command(const char *s)
> #endif
> }
>
> -#ifdef CONFIG_USE_AUTOBOOT_MENUKEY
> - if (menukey == CONFIG_AUTOBOOT_MENUKEY) {
> + if (IS_ENABLED(CONFIG_USE_AUTOBOOT_MENUKEY) &&
> + menukey == AUTOBOOT_MENUKEY) {
> s = env_get("menucmd");
> if (s)
> run_command_list(s, -1, 0);
> }
> -#endif /* CONFIG_USE_AUTOBOOT_MENUKEY */
> }
> --
> 2.22.0.657.g960e92d24f-goog
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
Re: [U-Boot] [PATCH v2 13/18] autoboot: Tidy up use of menukey
Hi Simon,
I think there's something funny going on with this line: #define
AUTOBOOT_MENUKEY CONFIG_USE_AUTOBOOT_MENUKEY
Did you mean: #define AUTOBOOT_MENUKEY CONFIG_AUTOBOOT_MENUKEY?
Best,
Da
On Mon, May 4, 2020 at 5:26 PM Da Xue wrote:
> Hi Simon,
>
> The Kconfig doesn't match the common/autoboot.c. Kconfig is using
> AUTOBOOT_USE_MENUKEY and common/autoboot.c is CONFIG_USE_AUTOBOOT_MENUKEY.
>
> Best,
> Da
>
> On Sat, Jul 20, 2019 at 11:56 PM Simon Glass wrote:
>
>> Move the variable to the top of the file and adjust the code which uses it
>> to use if() rather than #ifdef, to make it easier to read.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v2: None
>>
>> common/autoboot.c | 26 ++
>> 1 file changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/common/autoboot.c b/common/autoboot.c
>> index ad189a8ba2..9752470873 100644
>> --- a/common/autoboot.c
>> +++ b/common/autoboot.c
>> @@ -28,6 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>
>> /* Stored value of bootdelay, used by autoboot_command() */
>> static int stored_bootdelay;
>> +static int menukey;
>>
>> #ifdef CONFIG_AUTOBOOT_ENCRYPTION
>> #define AUTOBOOT_STOP_STR_SHA256 CONFIG_AUTOBOOT_STOP_STR_SHA256
>> @@ -35,6 +36,12 @@ static int stored_bootdelay;
>> #define AUTOBOOT_STOP_STR_SHA256 ""
>> #endif
>>
>> +#ifdef CONFIG_USE_AUTOBOOT_MENUKEY
>> +#define AUTOBOOT_MENUKEY CONFIG_USE_AUTOBOOT_MENUKEY
>> +#else
>> +#define AUTOBOOT_MENUKEY 0
>> +#endif
>> +
>> /*
>> * Use a "constant-length" time compare function for this
>> * hash compare:
>> @@ -224,10 +231,6 @@ static int abortboot_key_sequence(int bootdelay)
>> return abort;
>> }
>>
>> -#ifdef CONFIG_USE_AUTOBOOT_MENUKEY
>> -static int menukey;
>> -#endif
>> -
>> static int abortboot_single_key(int bootdelay)
>> {
>> int abort = 0;
>> @@ -250,13 +253,13 @@ static int abortboot_single_key(int bootdelay)
>> ts = get_timer(0);
>> do {
>> if (tstc()) { /* we got a key press */
>> + int key;
>> +
>> abort = 1; /* don't auto boot */
>> bootdelay = 0; /* no more delay*/
>> -# ifdef CONFIG_USE_AUTOBOOT_MENUKEY
>> - menukey = getc();
>> -# else
>> - (void) getc(); /* consume input*/
>> -# endif
>> + key = getc(); /* consume input */
>> + if
>> (IS_ENABLED(CONFIG_USE_AUTOBOOT_MENUKEY))
>> + menukey = key;
>> break;
>> }
>> udelay(1);
>> @@ -358,11 +361,10 @@ void autoboot_command(const char *s)
>> #endif
>> }
>>
>> -#ifdef CONFIG_USE_AUTOBOOT_MENUKEY
>> - if (menukey == CONFIG_AUTOBOOT_MENUKEY) {
>> + if (IS_ENABLED(CONFIG_USE_AUTOBOOT_MENUKEY) &&
>> + menukey == AUTOBOOT_MENUKEY) {
>> s = env_get("menucmd");
>> if (s)
>> run_command_list(s, -1, 0);
>> }
>> -#endif /* CONFIG_USE_AUTOBOOT_MENUKEY */
>> }
>> --
>> 2.22.0.657.g960e92d24f-goog
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>
[PATCH] autoboot: fix typos of CONFIG_AUTOBOOT_USE_MENUKEY
replace typo CONFIG_USE_AUTOBOOT_MENUKEY with CONFIG_AUTOBOOT_USE_MENUKEY
Signed-off-by: Da Xue
---
common/autoboot.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/autoboot.c b/common/autoboot.c
index 0bb08e7a4c..e201c01ece 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -44,8 +44,8 @@ static int menukey;
#define AUTOBOOT_STOP_STR_SHA256 ""
#endif
-#ifdef CONFIG_USE_AUTOBOOT_MENUKEY
-#define AUTOBOOT_MENUKEY CONFIG_USE_AUTOBOOT_MENUKEY
+#if defined(CONFIG_AUTOBOOT_USE_MENUKEY) &&
defined(CONFIG_AUTOBOOT_MENUKEY)
+#define AUTOBOOT_MENUKEY CONFIG_AUTOBOOT_MENUKEY
#else
#define AUTOBOOT_MENUKEY 0
#endif
@@ -282,7 +282,7 @@ static int abortboot_single_key(int bootdelay)
abort = 1; /* don't auto boot */
bootdelay = 0; /* no more delay*/
key = getchar();/* consume input*/
- if (IS_ENABLED(CONFIG_USE_AUTOBOOT_MENUKEY))
+ if (IS_ENABLED(CONFIG_AUTOBOOT_USE_MENUKEY))
menukey = key;
break;
}
@@ -388,7 +388,7 @@ void autoboot_command(const char *s)
disable_ctrlc(prev);/* restore Ctrl-C checking
*/
}
- if (IS_ENABLED(CONFIG_USE_AUTOBOOT_MENUKEY) &&
+ if (IS_ENABLED(CONFIG_AUTOBOOT_USE_MENUKEY) &&
menukey == AUTOBOOT_MENUKEY) {
s = env_get("menucmd");
if (s)
--
2.20.1
Re: [PATCH v2] disk: part_dos: update partition table entries after write
This breaks the build if CONFIG_CMD_MBR is enabled. Christian Melki sent a patch but it didn't get picked up? On Tue, Feb 2, 2021 at 9:32 AM Tom Rini wrote: > On Thu, Jan 28, 2021 at 09:10:07AM +0100, Gary Bisson wrote: > > > Fixes issues when switching from GPT to MBR partition tables. > > > > Signed-off-by: Gary Bisson > > Acked-by: Marek Szyprowski > > Applied to u-boot/master, thanks! > > -- > Tom >
Re: [PATCH] autoboot: fix typos of CONFIG_AUTOBOOT_USE_MENUKEY
Hi Tom, There is a distinction between the two flags CONFIG_AUTOBOOT_USE_MENUKEY AND CONFIG_AUTOBOOT_MENUKEY. config AUTOBOOT_USE_MENUKEY bool "Allow a specify key to run a menu from the environment" depends on !AUTOBOOT_KEYED help If a specific key is pressed to stop autoboot, then the commands in the environment variable 'menucmd' are executed before boot starts. config AUTOBOOT_MENUKEY int "ASCII value of boot key to show a menu" default 0 depends on AUTOBOOT_USE_MENUKEY help If this key is pressed to stop autoboot, then the commands in the environment variable 'menucmd' will be executed before boot starts. For example, 33 means "!" in ASCII, so pressing ! at boot would take this action. The modified patch that was merged causes Kconfig to remove both flags. I will send another patch. Best, Da On Thu, Jun 24, 2021 at 9:16 AM Tom Rini wrote: > On Mon, Jun 21, 2021 at 10:39:19PM -0400, Da Xue wrote: > > > replace typo CONFIG_USE_AUTOBOOT_MENUKEY with CONFIG_AUTOBOOT_USE_MENUKEY > > > > Signed-off-by: Da Xue > > Applied to u-boot/master, thanks! > > -- > Tom > -- Best, Da Xue General Manager Imprecision Systems LLC TEL: +1 (856) 562-6108 (WhatsApp) FAX: +1 856-624-3969
[PATCH] autoboot: fix MENUKEY
replace CONFIG_AUTOBOOT_USE_MENUKEY with CONFIG_AUTOBOOT_MENUKEY Signed-off-by: Da Xue --- common/autoboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/autoboot.c b/common/autoboot.c index c834db7323..26bfd64acc 100644 --- a/common/autoboot.c +++ b/common/autoboot.c @@ -45,7 +45,7 @@ static int menukey; #endif #ifdef CONFIG_AUTOBOOT_USE_MENUKEY -#define AUTOBOOT_MENUKEY CONFIG_AUTOBOOT_USE_MENUKEY +#define AUTOBOOT_MENUKEY CONFIG_AUTOBOOT_MENUKEY #else #define AUTOBOOT_MENUKEY 0 #endif -- 2.20.1
Re: [PATCH V2] spi: Update speed/mode on change
Hi Marek, This patch breaks meson_spifc: SF: Detected gd25lq128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB meson_spifc spi@8c80: Cannot set mode (err=-19) Failed to initialize SPI flash at 0:0 (error -19) Best, Da On Wed, Jun 30, 2021 at 12:49 PM Tom Rini wrote: > On Thu, Jun 10, 2021 at 02:00:00PM +0200, Marek Vasut wrote: > > > The spi_get_bus_and_cs() may be called on the same bus and chipselect > > with different frequency or mode. This is valid usecase, but the code > > fails to notify the controller of such a configuration change. Call > > spi_set_speed_mode() in case bus frequency or bus mode changed to let > > the controller update the configuration. > > > > The problem can easily be triggered using the sspi command: > > => sspi 0:0@1000 > > => sspi 0:0@2000 > > Without this patch, both transfers happen at 1000 Hz. With this patch, > > the later transfer happens correctly at 2000 Hz. > > > > Signed-off-by: Marek Vasut > > Cc: Jagan Teki > > Cc: Patrick Delaunay > > Applied to u-boot/master, thanks! > > -- > Tom >
Re: [PATCH V2] spi: Update speed/mode on change
On Fri, Jul 2, 2021 at 2:10 PM Marek Vasut wrote:
> On 7/2/21 8:03 PM, Da Xue wrote:
> > SF: Detected gd25lq128 with page size 256 Bytes, erase size 64 KiB, total
> > 16 MiB
> > SPI mode: 3
> > meson_spifc spi@8c80: Cannot set mode (err=-19)
> > Failed to initialize SPI flash at 0:0 (error -19)
> >
> > I added spi-rx-bus-width = <1> and spi-tx-bus-width = <1>
> >
> > On Fri, Jul 2, 2021 at 1:44 PM Marek Vasut wrote:
> >
> >> On 7/2/21 7:24 PM, Da Xue wrote:
> >>> Hi Marek,
> >>>
> >>> This patch breaks meson_spifc:
> >>>
> >>> SF: Detected gd25lq128 with page size 256 Bytes, erase size 64 KiB,
> total
> >>> 16 MiB
> >>> meson_spifc spi@8c80: Cannot set mode (err=-19)
> >>> Failed to initialize SPI flash at 0:0 (error -19)
> >>>
> >>> Best,
> >>>
> >>> Da
> >>>
> >>> On Wed, Jun 30, 2021 at 12:49 PM Tom Rini wrote:
> >>>
> >>>> On Thu, Jun 10, 2021 at 02:00:00PM +0200, Marek Vasut wrote:
> >>>>
> >>>>> The spi_get_bus_and_cs() may be called on the same bus and chipselect
> >>>>> with different frequency or mode. This is valid usecase, but the code
> >>>>> fails to notify the controller of such a configuration change. Call
> >>>>> spi_set_speed_mode() in case bus frequency or bus mode changed to let
> >>>>> the controller update the configuration.
> >>>>>
> >>>>> The problem can easily be triggered using the sspi command:
> >>>>> => sspi 0:0@1000
> >>>>> => sspi 0:0@2000
> >>>>> Without this patch, both transfers happen at 1000 Hz. With this
> patch,
> >>>>> the later transfer happens correctly at 2000 Hz.
> >>>>>
> >>>>> Signed-off-by: Marek Vasut
> >>>>> Cc: Jagan Teki
> >>>>> Cc: Patrick Delaunay
> >>>>
> >>>> Applied to u-boot/master, thanks!
> >>>>
> >>>> --
> >>>> Tom
> >>
> >> Seems like you're hitting this code in drivers/spi/meson_spifc.c
> >>
> >> 250 static int meson_spifc_set_mode(struct udevice *dev, uint mode)
> >> 251 {
> >> 252 struct meson_spifc_priv *spifc = dev_get_priv(dev);
> >> 253
> >> 254 if (mode & (SPI_CPHA | SPI_RX_QUAD | SPI_RX_DUAL |
> >> 255 SPI_TX_QUAD | SPI_TX_DUAL))
> >> 256 return -ENODEV;
> >>
> >> (the -ENODEV code doesn't look right, it should be some -EOPNOTSUP or
> so)
> >>
> >> Can you check which of the mode bits is set and triggers the condition ?
> >>
> >> I think you might be missing something like
> >> spi-rx-bus-width = <1>;
> >> spi-tx-bus-width = <1>;
> >> in your DT, but that's a guess.
>
> Can you check which of the mode bits is set and triggers the condition ?
>
> Also, where in the DT did you add spi-rx-bus-width = <1> and
> spi-tx-bus-width = <1> ?
>
> Finally, please do not top-post and keep the list on CC.
>
My apologies about the top-posting.
--- a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
+++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
@@ -304,6 +304,8 @@
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <8000>;
+ spi-rx-bus-width = <1>;
+ spi-tx-bus-width = <1>;
};
};
Re: [PATCH V2] spi: Update speed/mode on change
On Fri, Jul 2, 2021 at 3:06 PM Marek Vasut wrote:
> On 7/2/21 8:28 PM, Da Xue wrote:
> > On Fri, Jul 2, 2021 at 2:10 PM Marek Vasut wrote:
> >
> >> On 7/2/21 8:03 PM, Da Xue wrote:
> >>> SF: Detected gd25lq128 with page size 256 Bytes, erase size 64 KiB,
> total
> >>> 16 MiB
> >>> SPI mode: 3
> >>> meson_spifc spi@8c80: Cannot set mode (err=-19)
> >>> Failed to initialize SPI flash at 0:0 (error -19)
> >>>
> >>> I added spi-rx-bus-width = <1> and spi-tx-bus-width = <1>
> >>>
> >>> On Fri, Jul 2, 2021 at 1:44 PM Marek Vasut wrote:
> >>>
> >>>> On 7/2/21 7:24 PM, Da Xue wrote:
> >>>>> Hi Marek,
> >>>>>
> >>>>> This patch breaks meson_spifc:
> >>>>>
> >>>>> SF: Detected gd25lq128 with page size 256 Bytes, erase size 64 KiB,
> >> total
> >>>>> 16 MiB
> >>>>> meson_spifc spi@8c80: Cannot set mode (err=-19)
> >>>>> Failed to initialize SPI flash at 0:0 (error -19)
> >>>>>
> >>>>> Best,
> >>>>>
> >>>>> Da
> >>>>>
> >>>>> On Wed, Jun 30, 2021 at 12:49 PM Tom Rini
> wrote:
> >>>>>
> >>>>>> On Thu, Jun 10, 2021 at 02:00:00PM +0200, Marek Vasut wrote:
> >>>>>>
> >>>>>>> The spi_get_bus_and_cs() may be called on the same bus and
> chipselect
> >>>>>>> with different frequency or mode. This is valid usecase, but the
> code
> >>>>>>> fails to notify the controller of such a configuration change. Call
> >>>>>>> spi_set_speed_mode() in case bus frequency or bus mode changed to
> let
> >>>>>>> the controller update the configuration.
> >>>>>>>
> >>>>>>> The problem can easily be triggered using the sspi command:
> >>>>>>> => sspi 0:0@1000
> >>>>>>> => sspi 0:0@2000
> >>>>>>> Without this patch, both transfers happen at 1000 Hz. With this
> >> patch,
> >>>>>>> the later transfer happens correctly at 2000 Hz.
> >>>>>>>
> >>>>>>> Signed-off-by: Marek Vasut
> >>>>>>> Cc: Jagan Teki
> >>>>>>> Cc: Patrick Delaunay
> >>>>>>
> >>>>>> Applied to u-boot/master, thanks!
> >>>>>>
> >>>>>> --
> >>>>>> Tom
> >>>>
> >>>> Seems like you're hitting this code in drivers/spi/meson_spifc.c
> >>>>
> >>>> 250 static int meson_spifc_set_mode(struct udevice *dev, uint mode)
> >>>> 251 {
> >>>> 252 struct meson_spifc_priv *spifc = dev_get_priv(dev);
> >>>> 253
> >>>> 254 if (mode & (SPI_CPHA | SPI_RX_QUAD | SPI_RX_DUAL |
> >>>> 255 SPI_TX_QUAD | SPI_TX_DUAL))
> >>>> 256 return -ENODEV;
> >>>>
> >>>> (the -ENODEV code doesn't look right, it should be some -EOPNOTSUP or
> >> so)
> >>>>
> >>>> Can you check which of the mode bits is set and triggers the
> condition ?
> >>>>
> >>>> I think you might be missing something like
> >>>> spi-rx-bus-width = <1>;
> >>>> spi-tx-bus-width = <1>;
> >>>> in your DT, but that's a guess.
> >>
> >> Can you check which of the mode bits is set and triggers the condition ?
> >>
> >> Also, where in the DT did you add spi-rx-bus-width = <1> and
> >> spi-tx-bus-width = <1> ?
> >>
> >> Finally, please do not top-post and keep the list on CC.
> >>
> >
> > My apologies about the top-posting.
> >
> > --- a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> > +++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> > @@ -304,6 +304,8 @@
> > compatible = "jedec,spi-nor";
> > reg = <0>;
> > spi-max-frequency = <8000>;
> > + spi-rx-bus-width = <1>;
> > + spi-tx-bus-width = <1>;
> > };
> > };
>
> That should do the trick. Can you check which of the mode bits is set in
> meson_spifc_set_mode() and triggers the ENODEV condition ?
>
SPI_CPHA seems to be the culprit. I tried adding spi-cpha = <0> to no
avail.
Re: [PATCH V2] spi: Update speed/mode on change
On Fri, Jul 2, 2021 at 3:40 PM Marek Vasut wrote:
> On 7/2/21 9:35 PM, Da Xue wrote:
>
> [...]
>
> >>>>>> Seems like you're hitting this code in drivers/spi/meson_spifc.c
> >>>>>>
> >>>>>> 250 static int meson_spifc_set_mode(struct udevice *dev, uint mode)
> >>>>>> 251 {
> >>>>>> 252 struct meson_spifc_priv *spifc = dev_get_priv(dev);
> >>>>>> 253
> >>>>>> 254 if (mode & (SPI_CPHA | SPI_RX_QUAD | SPI_RX_DUAL |
> >>>>>> 255 SPI_TX_QUAD | SPI_TX_DUAL))
> >>>>>> 256 return -ENODEV;
> >>>>>>
> >>>>>> (the -ENODEV code doesn't look right, it should be some -EOPNOTSUP
> or
> >>>> so)
> >>>>>>
> >>>>>> Can you check which of the mode bits is set and triggers the
> >> condition ?
> >>>>>>
> >>>>>> I think you might be missing something like
> >>>>>> spi-rx-bus-width = <1>;
> >>>>>> spi-tx-bus-width = <1>;
> >>>>>> in your DT, but that's a guess.
> >>>>
> >>>> Can you check which of the mode bits is set and triggers the
> condition ?
> >>>>
> >>>> Also, where in the DT did you add spi-rx-bus-width = <1> and
> >>>> spi-tx-bus-width = <1> ?
> >>>>
> >>>> Finally, please do not top-post and keep the list on CC.
> >>>>
> >>>
> >>> My apologies about the top-posting.
> >>>
> >>> --- a/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> >>> +++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac.dts
> >>> @@ -304,6 +304,8 @@
> >>> compatible = "jedec,spi-nor";
> >>> reg = <0>;
> >>> spi-max-frequency = <8000>;
> >>> + spi-rx-bus-width = <1>;
> >>> + spi-tx-bus-width = <1>;
> >>> };
> >>>};
> >>
> >> That should do the trick. Can you check which of the mode bits is set in
> >> meson_spifc_set_mode() and triggers the ENODEV condition ?
> >>
> >
> > SPI_CPHA seems to be the culprit. I tried adding spi-cpha = <0> to no
> > avail.
>
> Can you find out what is setting the SPI_CPHA in the first place on your
> machine ?
>
The Kconfig was setting it to 3. I manually added the default mode (0) to
my board's config and it worked. Thanks Marek.
[PATCH] configs: libretech: set SPI mode to 0
Kconfig defaults to mode 3 if CONFIG_SF_DEFAULT_MODE is not set. It becomes an issue since meson_spifc does not support SPI_CPHA. Needed after commit e2e95e5e25421fbef499e21bf94a5339701f9a99. Signed-off-by:Da Xue --- configs/libretech-ac_defconfig | 1 + configs/libretech-cc_v2_defconfig| 1 + configs/libretech-s905d-pc_defconfig | 1 + configs/libretech-s912-pc_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/libretech-ac_defconfig b/configs/libretech-ac_defconfig index ec51f2ad38..9abbcad3c0 100644 --- a/configs/libretech-ac_defconfig +++ b/configs/libretech-ac_defconfig @@ -39,6 +39,7 @@ CONFIG_MMC_MESON_GX=y CONFIG_MTD=y CONFIG_DM_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_SF_DEFAULT_MODE=0x0 CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MESON_GXL=y diff --git a/configs/libretech-cc_v2_defconfig b/configs/libretech-cc_v2_defconfig index 97c8a9e47b..7dc6ed2f29 100644 --- a/configs/libretech-cc_v2_defconfig +++ b/configs/libretech-cc_v2_defconfig @@ -35,6 +35,7 @@ CONFIG_MMC_MESON_GX=y CONFIG_MTD=y CONFIG_DM_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_SF_DEFAULT_MODE=0x0 CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PHY_MESON_GXL=y CONFIG_DM_ETH=y diff --git a/configs/libretech-s905d-pc_defconfig b/configs/libretech-s905d-pc_defconfig index c0301a0aa0..93523c23cf 100644 --- a/configs/libretech-s905d-pc_defconfig +++ b/configs/libretech-s905d-pc_defconfig @@ -36,6 +36,7 @@ CONFIG_SARADC_MESON=y CONFIG_MMC_MESON_GX=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_SF_DEFAULT_MODE=0x0 CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y diff --git a/configs/libretech-s912-pc_defconfig b/configs/libretech-s912-pc_defconfig index e2faea6242..669f000f7f 100644 --- a/configs/libretech-s912-pc_defconfig +++ b/configs/libretech-s912-pc_defconfig @@ -35,6 +35,7 @@ CONFIG_SARADC_MESON=y CONFIG_MMC_MESON_GX=y CONFIG_MTD=y CONFIG_DM_SPI_FLASH=y +CONFIG_SF_DEFAULT_MODE=0x0 CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y -- 2.30.2
Re: Pull request for efi-2021-07-rc5-2
On Wed, Jun 30, 2021 at 8:06 AM Tom Rini wrote:
> On Mon, Jun 28, 2021 at 09:47:53PM +0200, Heinrich Schuchardt wrote:
>
> > Dear Tom,
> >
> > I have removed the one patch for better EFI/DM integration that caused
> > sandbox test problems on my last pull request. This topic needs more
> > coordination with Simon.
> >
> > Gitlab CI showed no problems:
> > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/7968
> >
> > The following changes since commit
> 4d8c21da4170e7c1d38c0106898e0d8347b4f0ff:
> >
> > Merge tag 'u-boot-imx-20210625' of
> > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2021-06-25 13:33:47
> > -0400)
> >
> > are available in the Git repository at:
> >
> > https://source.denx.de/u-boot/custodians/u-boot-efi.git
> > tags/efi-2021-07-rc5-2
> >
> > for you to fetch changes up to 70e80666f26a516096f3787e884d42818d8b4087:
> >
> > smbios: Fix SMBIOS tables (2021-06-28 19:57:13 +0200)
> >
>
> Applied to u-boot/master, thanks!
>
> --
> Tom
>
Hi Heinrich and Ilias,
We use SMBIOS/DMI entries to identify our boards. For some reason the
device tree entries are not being passed to /sys/class/virtual/dmi/id. I'm
using master as of this morning.
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
...
[0.00] Linux version 5.10.45 (dxue@build-server)
(aarch64-buildroot-linux-musl-gcc.br_real (Buildroot
2019.08-10705-g7cb51d4843-dirty) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #21
[0.00] Machine model: Libre Computer AML-S805X-AC
...
[0.00] efi: ESRT=0x3aeea040 RTPROP=0x3aee8040 SMBIOS=0x3aee4000
RNG=0x394ee040 MEMRESERVE=0x394ed040
/sys/firmware/devicetree/base/smbios/smbios # grep -r . *
baseboard/manufacturer:libre-computer
baseboard/product:aml-s805x-ac
baseboard/name:baseboard
chassis/manufacturer:libre-computer
chassis/product:aml-s805x-ac
chassis/name:chassis
name:smbios
system/manufacturer:libre-computer
system/product:aml-s805x-ac
system/name:system
/sys/firmware/devicetree/base/smbios/smbios # cd /sys/devices/virtual/dmi/id
/sys/devices/virtual/dmi/id # grep -r . *
bios_date:07/03/2021
bios_release:21.7
bios_vendor:U-Boot
bios_version:2021.07-rc5+
board_name:Unknown Product
board_vendor:Unknown
chassis_type:3
chassis_vendor:Unknown
modalias:dmi:bvnU-Boot:bvr2021.07-rc5+:bd07/03/2021:br21.7:svnUnknown:pnUnknownProduct:pvr:rvnUnknown:rnUnknownProduct:rvr:cvnUnknown:ct3:cvr:
power/runtime_active_time:0
power/runtime_status:unsupported
power/runtime_suspended_time:0
power/control:auto
product_name:Unknown Product
sys_vendor:Unknown
uevent:MODALIAS=dmi:bvnU-Boot:bvr2021.07-rc5+:bd07/03/2021:br21.7:svnUnknown:pnUnknownProduct:pvr:rvnUnknown:rnUnknownProduct:rvr:cvnUnknown:ct3:cvr:
diff --git a/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
b/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
index 39270ea71c..02177c64a6 100644
--- a/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
+++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
@@ -5,3 +5,26 @@
*/
#include "meson-gxl-u-boot.dtsi"
+
+/ {
+ smbios {
+ compatible = "u-boot,sysinfo-smbios";
+
+ smbios {
+ system {
+ manufacturer = "libre-computer";
+ product = "aml-s805x-ac";
+ };
+
+ baseboard {
+ manufacturer = "libre-computer";
+ product = "aml-s805x-ac";
+ };
+
+ chassis {
+ manufacturer = "libre-computer";
+ };
+ };
+ };
+};
Any ideas?
Best,
Da
Re: Pull request for efi-2021-07-rc5-2
On Sat, Jul 3, 2021 at 9:36 AM Heinrich Schuchardt
wrote:
> Am 3. Juli 2021 14:46:39 MESZ schrieb Da Xue :
> >On Wed, Jun 30, 2021 at 8:06 AM Tom Rini wrote:
> >
> >> On Mon, Jun 28, 2021 at 09:47:53PM +0200, Heinrich Schuchardt wrote:
> >>
> >> > Dear Tom,
> >> >
> >> > I have removed the one patch for better EFI/DM integration that
> >caused
> >> > sandbox test problems on my last pull request. This topic needs
> >more
> >> > coordination with Simon.
> >> >
> >> > Gitlab CI showed no problems:
> >> >
> >https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/7968
> >> >
> >> > The following changes since commit
> >> 4d8c21da4170e7c1d38c0106898e0d8347b4f0ff:
> >> >
> >> > Merge tag 'u-boot-imx-20210625' of
> >> > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2021-06-25
> >13:33:47
> >> > -0400)
> >> >
> >> > are available in the Git repository at:
> >> >
> >> > https://source.denx.de/u-boot/custodians/u-boot-efi.git
> >> > tags/efi-2021-07-rc5-2
> >> >
> >> > for you to fetch changes up to
> >70e80666f26a516096f3787e884d42818d8b4087:
> >> >
> >> > smbios: Fix SMBIOS tables (2021-06-28 19:57:13 +0200)
> >> >
> >>
> >> Applied to u-boot/master, thanks!
> >>
> >> --
> >> Tom
> >>
> >
> >Hi Heinrich and Ilias,
> >
> >We use SMBIOS/DMI entries to identify our boards. For some reason the
> >device tree entries are not being passed to /sys/class/virtual/dmi/id.
> >I'm
> >using master as of this morning.
> >
> >EFI stub: Booting Linux Kernel...
> >EFI stub: Using DTB from configuration table
> >...
> >[0.00] Linux version 5.10.45 (dxue@build-server)
> >(aarch64-buildroot-linux-musl-gcc.br_real (Buildroot
> >2019.08-10705-g7cb51d4843-dirty) 10.3.0, GNU ld (GNU Binutils) 2.36.1)
> >#21
> >[0.00] Machine model: Libre Computer AML-S805X-AC
> >...
> >[0.00] efi: ESRT=0x3aeea040 RTPROP=0x3aee8040 SMBIOS=0x3aee4000
> >RNG=0x394ee040 MEMRESERVE=0x394ed040
> >
> >/sys/firmware/devicetree/base/smbios/smbios # grep -r . *
> >baseboard/manufacturer:libre-computer
> >baseboard/product:aml-s805x-ac
> >baseboard/name:baseboard
> >chassis/manufacturer:libre-computer
> >chassis/product:aml-s805x-ac
> >chassis/name:chassis
>
> This matces the device tree segment below.
>
> >name:smbios
> >system/manufacturer:libre-computer
> >system/product:aml-s805x-ac
> >system/name:system
> >/sys/firmware/devicetree/base/smbios/smbios # cd
> >/sys/devices/virtual/dmi/id
> >/sys/devices/virtual/dmi/id # grep -r . *
> >bios_date:07/03/2021
> >bios_release:21.7
> >bios_vendor:U-Boot
> >bios_version:2021.07-rc5+
> >board_name:Unknown Product
> >board_vendor:Unknown
> >chassis_type:3
> >chassis_vendor:Unknown
>
> All that is marked unknown is not in your device-tree below.
>
> What are you expecting here?
> Was it here before the pull request?
>
> Best regards
>
> Heinrich
>
>
> >modalias:dmi:bvnU-Boot:bvr2021.07-rc5+:bd07/03/2021:br21.7:svnUnknown:pnUnknownProduct:pvr:rvnUnknown:rnUnknownProduct:rvr:cvnUnknown:ct3:cvr:
> >power/runtime_active_time:0
> >power/runtime_status:unsupported
> >power/runtime_suspended_time:0
> >power/control:auto
> >product_name:Unknown Product
> >sys_vendor:Unknown
>
> >uevent:MODALIAS=dmi:bvnU-Boot:bvr2021.07-rc5+:bd07/03/2021:br21.7:svnUnknown:pnUnknownProduct:pvr:rvnUnknown:rnUnknownProduct:rvr:cvnUnknown:ct3:cvr:
> >
> >diff --git a/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
> >b/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
> >index 39270ea71c..02177c64a6 100644
> >--- a/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
> >+++ b/arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi
> >@@ -5,3 +5,26 @@
> > */
> >
> > #include "meson-gxl-u-boot.dtsi"
> >+
> >+/ {
> >+ smbios {
> >+ compatible = "u-boot,sysinfo-smbios";
> >+
> >+ smbios {
> >+ system {
> >+ manufacturer = "libre-computer";
> >+ product = "aml-s805x-ac";
> >+ };
> >+
> >+ baseboard {
> >+ manufacturer = "libre-computer";
> >+ product = "aml-s805x-ac";
> >+ };
> >+
> >+ chassis {
> >+ manufacturer = "libre-computer";
> >+ };
> >+ };
> >+ };
> >+};
> >
> >Any ideas?
> >
> >Best,
> >Da
>
> There's two issues:
1) I just saw this patch: "x86: Provide default SMBIOS
manufacturer/product". Should we add the same thing for ARM or maybe
generically across the board?
2) The DMI entries previously took CONFIG_SYS_VENDOR and CONFIG_SYS_BOARD
entries as manufacturer and product respectively. Now those entries become
Unknown and Unknown Product.
Best,
Da
Re: [PATCH 2/3] ram: rk3328: add support ddr4 init
Hi Kever,
Any chance you will be adding higher DDR4 speeds like 800/933/1066/1200?
333MHz is kind of limiting. We are trying to switch to upstream u-boot for
ROC-RK3328-CC and ROC-RK3399-PC.
Best,
Da
On Tue, Jan 7, 2020 at 2:16 AM Kever Yang wrote:
> From: YouMin Chen
>
> Add rk3328-sdram-ddr4-666.dtsi for support ddr4 init.
>
> Signed-off-by: YouMin Chen
> Signed-off-by: Kever Yang
> ---
>
> arch/arm/dts/rk3328-sdram-ddr4-666.dtsi | 216
> 1 file changed, 216 insertions(+)
> create mode 100644 arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
>
> diff --git a/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
> b/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
> new file mode 100644
> index 00..0859649a69
> --- /dev/null
> +++ b/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd.
> +
> +&dmc {
> + rockchip,sdram-params = <
> + 0x1
> + 0xA
> + 0x2
> + 0x1
> + 0x0
> + 0x0
> + 0x11
> + 0x0
> + 0x11
> + 0x0
> + 0
> +
> + 0x94291288
> + 0x
> + 0x0027
> + 0x0462
> + 0x0015
> + 0x0242
> + 0x00ff
> +
> + 333
> + 0
> + 1
> + 0
> + 0
> +
> + 0x
> + 0x43049010
> + 0x0064
> + 0x0028003b
> + 0x00d0
> + 0x00020053
> + 0x00d4
> + 0x0022
> + 0x00d8
> + 0x0100
> + 0x00dc
> + 0x0004
> + 0x00e0
> + 0x
> + 0x00e4
> + 0x0011
> + 0x00e8
> + 0x0420
> + 0x00ec
> + 0x0400
> + 0x00f4
> + 0x000f011f
> + 0x0100
> + 0x09060b06
> + 0x0104
> + 0x00020209
> + 0x0108
> + 0x0505040a
> + 0x010c
> + 0x0040400c
> + 0x0110
> + 0x05030206
> + 0x0114
> + 0x03030202
> + 0x0120
> + 0x03030b03
> + 0x0124
> + 0x00020208
> + 0x0180
> + 0x0140
> + 0x0184
> + 0x
> + 0x0190
> + 0x07030003
> + 0x0198
> + 0x05001100
> + 0x01a0
> + 0xc043
> + 0x0240
> + 0x06000604
> + 0x0244
> + 0x0201
> + 0x0250
> + 0x0f00
> + 0x0490
> + 0x0001
> + 0x
> + 0x
> + 0x
> + 0x
> +
> + 0x0004
> + 0x000c
> + 0x0028
> + 0x000a
> + 0x002c
> + 0x
> + 0x0030
> + 0x0009
> + 0x
> + 0x
> +
> + 0x77
> + 0x88
> + 0x79
> + 0x79
> + 0x87
> + 0x97
> + 0x87
> + 0x78
> + 0x77
> + 0x78
> + 0x87
> + 0x88
> + 0x87
> + 0x87
> + 0x77
> +
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x69
> + 0x9
> +
> + 0x77
> + 0x78
> + 0x77
> + 0x78
> + 0x77
> + 0x78
> + 0x77
> + 0x78
> + 0x77
> + 0x79
> + 0x9
> +
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x78
> + 0x69
> + 0x9
> +
> + 0x77
> + 0x78
> + 0x77
> + 0x77
> + 0x77
> + 0x77
> + 0x77
> + 0x77
> + 0x77
> + 0x79
> + 0x9
> +
> + 0x78
> + 0x78
> +
Re: Increasing stabilization time in sunxi_mmc_core_init
On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec wrote: > > Hi! > > Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara napisal(a): > > On 21/07/2022 12:03, Da Xue wrote: > > > > Hi Da, > > > > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5). u-boot > > > gets stuck in SPL with this message for SD/eMMC respectively. > > > > > > Trying to boot from MMC1 or Trying to boot from MMC2 > > > > > > I tested about 20 MicroSD cards from different brands and some were > > > happy and some were not. Increasing the udelay to 8-10ms in > > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to fix > > > the issue for the MicroSD cards. > > > > That's interesting, thanks for the report. I don't remember hearing of > > issues with MMC before, at least not in the SPL. > > I certainly experienced this issue on board in question. I vaguely remember > asking about this issue on IRC. I also tried all sorts of tweaks, but it never > occured to me that mmc reset timeout would be too short. > > Da, how did you find this? Someone on the Armbian forum posted that they had the same problem with eMMC so I got suspicious. I scoped the MicroSD clock line and realized the frequency goes high and then drops to very low as if it never found the card. I had a hunch it was a stabilization delay and got lucky. > > I only test one other H5 board occasionally, namely OrangePi PC2, but I never > observed such issue there. I always needed about 5 attempts to boot ALL-H3-CC- > H5 board, but once it's cold booted, warm boots always succeed. I had run into this too so it didn't make any sense. I tried 5ms and it helped on some cards but not others. I know the Orange Pis do not have the series resistor for ESD protection of the SD GPIOs but that shouldn't affect this. So...who knows? > > Best regards, > Jernej > > > It's a bit odd that waiting after the *controller* reset should affect > > SD cards, and 1ms seems plenty for just the reset. > > I just checked and at least the SOFT_RESET and FIFO_RESET bits are self > > clearing. Can you try to use wait_for_bit_le32() to wait for those parts > > to finish? See sun8i_emac_eth_start() for an example. I tested some more and here's the data: sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms Given this, I don't think it's an issue with the bit set delays. Might need more than 10ms even. I didn't change the udelay in probe. > > > > And since you mentioned it's card related: can you check whether the > > delay is actually needed somewhere else, later? At some point where we > > wait to the card to response, for instance? > > > > I am not against taking this patch, if it fixes problems for you, but > > just want to avoid that it papers over other issues. > > > > Cheers, > > Andre > > > > > Author: Da Xue > > > Date: Wed Jul 20 19:11:55 2022 -0400 > > > > > > sunxi: raise stabilization time for mmc from 1ms to 8ms > > > > > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c > > > index 1bb7b6d0e9..499e057725 100644 > > > --- a/drivers/mmc/sunxi_mmc.c > > > +++ b/drivers/mmc/sunxi_mmc.c > > > @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc) > > > > > > /* Reset controller */ > > > writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl); > > > > > > - udelay(1000); > > > + udelay(8000); This might need to be even higher. Like 20ms. > > > > > > return 0; > > > > > > } > > > > > > I don't know the implications of this change so I am seeking feedback. > > > Are other boards having this issue as well or is it specific to our > > > hardware? > > > > > > Best, > > > Da >
Re: Re: Increasing stabilization time in sunxi_mmc_core_init
On Thu, Jul 21, 2022 at 4:05 PM Jernej Škrabec wrote:
>
> Dne četrtek, 21. julij 2022 ob 21:56:35 CEST je Da Xue napisal(a):
> > On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec
> >
> > wrote:
> > > Hi!
> > >
> > > Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara napisal(a):
> > > > On 21/07/2022 12:03, Da Xue wrote:
> > > >
> > > > Hi Da,
> > > >
> > > > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5). u-boot
> > > > > gets stuck in SPL with this message for SD/eMMC respectively.
> > > > >
> > > > > Trying to boot from MMC1 or Trying to boot from MMC2
> > > > >
> > > > > I tested about 20 MicroSD cards from different brands and some were
> > > > > happy and some were not. Increasing the udelay to 8-10ms in
> > > > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to fix
> > > > > the issue for the MicroSD cards.
> > > >
> > > > That's interesting, thanks for the report. I don't remember hearing of
> > > > issues with MMC before, at least not in the SPL.
> > >
> > > I certainly experienced this issue on board in question. I vaguely
> > > remember
> > > asking about this issue on IRC. I also tried all sorts of tweaks, but it
> > > never occured to me that mmc reset timeout would be too short.
> > >
> > > Da, how did you find this?
> >
> > Someone on the Armbian forum posted that they had the same problem
> > with eMMC so I got suspicious. I scoped the MicroSD clock line and
> > realized the frequency goes high and then drops to very low as if it
> > never found the card.
> > I had a hunch it was a stabilization delay and got lucky.
> >
> > > I only test one other H5 board occasionally, namely OrangePi PC2, but I
> > > never observed such issue there. I always needed about 5 attempts to boot
> > > ALL-H3-CC- H5 board, but once it's cold booted, warm boots always
> > > succeed.
> >
> > I had run into this too so it didn't make any sense. I tried 5ms and
> > it helped on some cards but not others.
> > I know the Orange Pis do not have the series resistor for ESD
> > protection of the SD GPIOs but that shouldn't affect this.
> > So...who knows?
> >
> > > Best regards,
> > > Jernej
> > >
> > > > It's a bit odd that waiting after the *controller* reset should affect
> > > > SD cards, and 1ms seems plenty for just the reset.
> > > > I just checked and at least the SOFT_RESET and FIFO_RESET bits are self
> > > > clearing. Can you try to use wait_for_bit_le32() to wait for those parts
> > > > to finish? See sun8i_emac_eth_start() for an example.
> >
> > I tested some more and here's the data:
> > sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms
> > sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms
> > sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
> > Given this, I don't think it's an issue with the bit set delays. Might
> > need more than 10ms even. I didn't change the udelay in probe.
>
> Idea here is that we wouldn't need to determine the appropriate delay, but
> instead, wait_for_bit_le32() would monitor reset bit and continue only after
> reset bit would clear itself. Hopefully that happens after everything is
> stable.
I changed it to 50ms delay
writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
if (wait_for_bit_le32( &priv->reg->gctrl,
SUNXI_MMC_GCTRL_RESET, false, 50, false)) {
printf("%s: Timeout\n", __func__);
return ret;
}
and that seems to work. Shall I send the patch?
>
> Best regards,
> Jernej
>
> >
> > > > And since you mentioned it's card related: can you check whether the
> > > > delay is actually needed somewhere else, later? At some point where we
> > > > wait to the card to response, for instance?
> > > >
> > > > I am not against taking this patch, if it fixes problems for you, but
> > > > just want to avoid that it papers over other issues.
> > > >
> > > > Cheers,
> > > > Andre
> > > >
> > > > > Author: Da Xue
> > > > > Date: Wed Jul 20 19:11:55 2022 -0400
> > > > >
> > > > > sunxi: raise stabilization time for mmc from 1ms to 8ms
> > > > >
> > > > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > > > > index 1bb7b6d0e9..499e057725 100644
> > > > > --- a/drivers/mmc/sunxi_mmc.c
> > > > > +++ b/drivers/mmc/sunxi_mmc.c
> > > > > @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
> > > > >
> > > > > /* Reset controller */
> > > > > writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
> > > > >
> > > > > - udelay(1000);
> > > > > + udelay(8000);
> >
> > This might need to be even higher. Like 20ms.
> >
> > > > > return 0;
> > > > >
> > > > > }
> > > > >
> > > > > I don't know the implications of this change so I am seeking feedback.
> > > > > Are other boards having this issue as well or is it specific to our
> > > > > hardware?
> > > > >
> > > > > Best,
> > > > > Da
>
>
Re: Re: Re: Increasing stabilization time in sunxi_mmc_core_init
On Thu, Jul 21, 2022 at 4:49 PM Jernej Škrabec wrote: > > Dne četrtek, 21. julij 2022 ob 22:33:09 CEST je Da Xue napisal(a): > > On Thu, Jul 21, 2022 at 4:05 PM Jernej Škrabec > wrote: > > > Dne četrtek, 21. julij 2022 ob 21:56:35 CEST je Da Xue napisal(a): > > > > On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec > > > > > > > > wrote: > > > > > Hi! > > > > > > > > > > Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara > napisal(a): > > > > > > On 21/07/2022 12:03, Da Xue wrote: > > > > > > > > > > > > Hi Da, > > > > > > > > > > > > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5). > > > > > > > u-boot > > > > > > > gets stuck in SPL with this message for SD/eMMC respectively. > > > > > > > > > > > > > > Trying to boot from MMC1 or Trying to boot from MMC2 > > > > > > > > > > > > > > I tested about 20 MicroSD cards from different brands and some > > > > > > > were > > > > > > > happy and some were not. Increasing the udelay to 8-10ms in > > > > > > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to > > > > > > > fix > > > > > > > the issue for the MicroSD cards. > > > > > > > > > > > > That's interesting, thanks for the report. I don't remember hearing > > > > > > of > > > > > > issues with MMC before, at least not in the SPL. > > > > > > > > > > I certainly experienced this issue on board in question. I vaguely > > > > > remember > > > > > asking about this issue on IRC. I also tried all sorts of tweaks, but > > > > > it > > > > > never occured to me that mmc reset timeout would be too short. > > > > > > > > > > Da, how did you find this? > > > > > > > > Someone on the Armbian forum posted that they had the same problem > > > > with eMMC so I got suspicious. I scoped the MicroSD clock line and > > > > realized the frequency goes high and then drops to very low as if it > > > > never found the card. > > > > I had a hunch it was a stabilization delay and got lucky. > > > > > > > > > I only test one other H5 board occasionally, namely OrangePi PC2, but > > > > > I > > > > > never observed such issue there. I always needed about 5 attempts to > > > > > boot > > > > > ALL-H3-CC- H5 board, but once it's cold booted, warm boots always > > > > > succeed. > > > > > > > > I had run into this too so it didn't make any sense. I tried 5ms and > > > > it helped on some cards but not others. > > > > I know the Orange Pis do not have the series resistor for ESD > > > > protection of the SD GPIOs but that shouldn't affect this. > > > > So...who knows? > > > > > > > > > Best regards, > > > > > Jernej > > > > > > > > > > > It's a bit odd that waiting after the *controller* reset should > > > > > > affect > > > > > > SD cards, and 1ms seems plenty for just the reset. > > > > > > I just checked and at least the SOFT_RESET and FIFO_RESET bits are > > > > > > self > > > > > > clearing. Can you try to use wait_for_bit_le32() to wait for those > > > > > > parts > > > > > > to finish? See sun8i_emac_eth_start() for an example. > > > > > > > > I tested some more and here's the data: > > > > sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms > > > > sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms > > > > sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms > > > > Given this, I don't think it's an issue with the bit set delays. Might > > > > need more than 10ms even. I didn't change the udelay in probe. > > > > > > Idea here is that we wouldn't need to determine the appropriate delay, but > > > instead, wait_for_bit_le32() would monitor reset bit and continue only > > > after reset bit would clear itself. Hopefully that happens after > > > everything is stable. > > > > I changed it to 50ms delay > > > > wr
Re: Re: Re: Increasing stabilization time in sunxi_mmc_core_init
On Thu, Jul 21, 2022 at 4:58 PM Da Xue wrote: > > On Thu, Jul 21, 2022 at 4:49 PM Jernej Škrabec > wrote: > > > > Dne četrtek, 21. julij 2022 ob 22:33:09 CEST je Da Xue napisal(a): > > > On Thu, Jul 21, 2022 at 4:05 PM Jernej Škrabec > > wrote: > > > > Dne četrtek, 21. julij 2022 ob 21:56:35 CEST je Da Xue napisal(a): > > > > > On Thu, Jul 21, 2022 at 11:14 AM Jernej Škrabec > > > > > > > > > > wrote: > > > > > > Hi! > > > > > > > > > > > > Dne četrtek, 21. julij 2022 ob 13:28:59 CEST je Andre Przywara > > napisal(a): > > > > > > > On 21/07/2022 12:03, Da Xue wrote: > > > > > > > > > > > > > > Hi Da, > > > > > > > > > > > > > > > Users were reporting non-boot on our H5 boards (ALL-H3-CC-H5). > > > > > > > > u-boot > > > > > > > > gets stuck in SPL with this message for SD/eMMC respectively. > > > > > > > > > > > > > > > > Trying to boot from MMC1 or Trying to boot from MMC2 > > > > > > > > > > > > > > > > I tested about 20 MicroSD cards from different brands and some > > > > > > > > were > > > > > > > > happy and some were not. Increasing the udelay to 8-10ms in > > > > > > > > drivers/mmc/sunxi_mmc.c sunxi_mmc_core_init after reset seems to > > > > > > > > fix > > > > > > > > the issue for the MicroSD cards. > > > > > > > > > > > > > > That's interesting, thanks for the report. I don't remember > > > > > > > hearing > > > > > > > of > > > > > > > issues with MMC before, at least not in the SPL. > > > > > > > > > > > > I certainly experienced this issue on board in question. I vaguely > > > > > > remember > > > > > > asking about this issue on IRC. I also tried all sorts of tweaks, > > > > > > but > > > > > > it > > > > > > never occured to me that mmc reset timeout would be too short. > > > > > > > > > > > > Da, how did you find this? > > > > > > > > > > Someone on the Armbian forum posted that they had the same problem > > > > > with eMMC so I got suspicious. I scoped the MicroSD clock line and > > > > > realized the frequency goes high and then drops to very low as if it > > > > > never found the card. > > > > > I had a hunch it was a stabilization delay and got lucky. > > > > > > > > > > > I only test one other H5 board occasionally, namely OrangePi PC2, > > > > > > but > > > > > > I > > > > > > never observed such issue there. I always needed about 5 attempts to > > > > > > boot > > > > > > ALL-H3-CC- H5 board, but once it's cold booted, warm boots always > > > > > > succeed. > > > > > > > > > > I had run into this too so it didn't make any sense. I tried 5ms and > > > > > it helped on some cards but not others. > > > > > I know the Orange Pis do not have the series resistor for ESD > > > > > protection of the SD GPIOs but that shouldn't affect this. > > > > > So...who knows? > > > > > > > > > > > Best regards, > > > > > > Jernej > > > > > > > > > > > > > It's a bit odd that waiting after the *controller* reset should > > > > > > > affect > > > > > > > SD cards, and 1ms seems plenty for just the reset. > > > > > > > I just checked and at least the SOFT_RESET and FIFO_RESET bits are > > > > > > > self > > > > > > > clearing. Can you try to use wait_for_bit_le32() to wait for those > > > > > > > parts > > > > > > > to finish? See sun8i_emac_eth_start() for an example. After more extensive testing with 5 MicroSD cards, 2 of them are still inconsistent with waiting for SOFT_RESET and FIFO_RESET vs a hard 20ms delay. I even tried putting a delay of 1ms after they cleared to no avail. I'm curious how larger 1TB MicroSD cards behave now but I don't have any samples. > > > > > > > > > > I tested some mor
[PATCH] sunxi-mmc: increase stabilization delay from 1ms to 20ms
Some users experienced problems booting u-boot from SPL hanging here:
Trying to boot from MMC1 or Trying to boot from MMC2
This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC.
Increasing the delay after mmc reset fixes these boot problems.
Some MicroSD cards are impacted more than others so it is possible that
MicroSD internals need time to stabilize. Below is some failure data.
sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms
sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms
sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
A quick comparison of schematics show series resistors for ESD
protection on the MicroSD GPIOs not present on all H3/H5 boards.
It is not known if this is related to the issue.
This patch adds a fixed 20ms delay to mmc init to mitigate the problem.
If boot time optimization is required and the platform does not require
the delay. The delay can be replaced with:
writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
if (wait_for_bit_le32( &priv->reg->gctrl,
SUNXI_MMC_GCTRL_RESET, false, 20, false)) {
printf("%s: Timeout\n", __func__);
return -ETIMEDOUT;
}
Signed-off-by: Da Xue
---
drivers/mmc/sunxi_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 1bb7b6d0e9..f7942b69ce 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
/* Reset controller */
writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
- udelay(1000);
+ udelay(2);
return 0;
}
--
2.30.2
Re: [PATCH] sunxi-mmc: increase stabilization delay from 1ms to 20ms
On Fri, Jul 22, 2022 at 1:56 PM Jernej Škrabec wrote:
>
> Dne petek, 22. julij 2022 ob 18:55:14 CEST je Andre Przywara napisal(a):
> > On 21/07/2022 23:08, Da Xue wrote:
> >
> > Hi,
> >
> > > Some users experienced problems booting u-boot from SPL hanging here:
> > >
> > > Trying to boot from MMC1 or Trying to boot from MMC2
> > >
> > > This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC.
> > > Increasing the delay after mmc reset fixes these boot problems.
> > > Some MicroSD cards are impacted more than others so it is possible that
> > > MicroSD internals need time to stabilize. Below is some failure data.
> > >
> > > sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms
> > > sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms
> > > sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
> > >
> > > A quick comparison of schematics show series resistors for ESD
> > > protection on the MicroSD GPIOs not present on all H3/H5 boards.
> > > It is not known if this is related to the issue.
> > >
> > > This patch adds a fixed 20ms delay to mmc init to mitigate the problem.
> > > If boot time optimization is required and the platform does not require
> > > the delay. The delay can be replaced with:
> > >
> > > writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
> > > if (wait_for_bit_le32( &priv->reg->gctrl,
> > > SUNXI_MMC_GCTRL_RESET, false, 20, false)) {
> > > printf("%s: Timeout\n", __func__);
> > > return -ETIMEDOUT;
> > > }
> >
> > So what about adding this for everyone (we should have it regardless) then?
I think it would be good to add for everyone. This only happens in SPL
so the impact is limited in terms of time cost.
> >
> > And then have an extra Kconfig option to specify an extra delay, and
> > define this only in your board defconfig? Because IIUC this is specific
> > to your board?
I only have my boards to test. I'm sure there are other devices that have the
same issue. I don't think it's exclusive to our boards.
> >
> > And as I mentioned: it looks odd to have this here and have it fixing
> > your SD card problems:
> > - The soft reset should reset just the internal controller logic (MMC
> > state machine and FIFOs), this shouldn't affect cards. IIUC, nothing
> > should happen on the MMC *pins* because of this operation.
> > - Why isn't this a problem for U-Boot proper, and Linux, FWIW?
>
> As I said before, I have issue only at cold boot in SPL. Once I pass this
> point, it works all the time, even if rebooted. Why is that so it's unclear.
>
> Thinking about this a bit, I have another question. How is it possible that
> BROM manages to read SD card just fine and loads SPL beforehand? Is it using
> lower speed? It also couldn't be power issue, since card must have been
> properly powered up by BROM...
Is the bootrom using SPI mode on first boot? If that is the case, a transition
would take time and may explain the necessity of this.
>
> Best regards,
> Jernej
>
> >
> > Cheers,
> > Andre
> >
> > > Signed-off-by: Da Xue
> > > ---
> > >
> > > drivers/mmc/sunxi_mmc.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > > index 1bb7b6d0e9..f7942b69ce 100644
> > > --- a/drivers/mmc/sunxi_mmc.c
> > > +++ b/drivers/mmc/sunxi_mmc.c
> > > @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
> > >
> > >/* Reset controller */
> > >writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
> > >
> > > - udelay(1000);
> > > + udelay(2);
> > >
> > >return 0;
> > >
> > > }
>
>
>
>
Re: [U-Boot] U-Boot/EBBR plugfest at ELC-EU?
My flight out of Lyon is on the 31st. Happy to work on it anytime during the conference. On Thu, Aug 8, 2019, 4:06 AM Grant Likely wrote: > > > On 28/06/2019 09:19, Grant Likely wrote: > > Quick poll: who would be interested in a U-Boot/EBBR plugfest event > collocates with ELC-EU this year (week of 28th Oct)? > > > > In the EBBR meetings we’ve tossed around the idea of an U-Boot/EBBR > plugfest to work out compatibility issues between OS distros and upstream > U-Boot SBC support. The idea is to get a number of SBCs supported by > mainline U-Boot with UEFI features turned on, along with U-Boot & OS > developers and hold a 1 day debug sprint to work out how many platforms can > work with ‘stock’ OS images. Details to be worked out if this looks viable. > > > > I’ve asked the LF folks if they have space on either Thursday 31st Oct > or Friday 1st Nov. They are checking availability, but no commitments have > been made. It would help to know if this date and location is feasible. > > > > What do you think? Would you come to a plug fest attached to ELC-EU? > Would you be interested in helping to organise? Or, is there another time & > location that would work better? > > > > Cheers, > > g. > > At this point I've only had about 3 people say they'd be able to attend. > That's not enough for critical mass. I think we should defer to another > event. > > I'm going to tell the LF that they can release the space they've > reserved for us and I'll look at the calendar and come up with some new > options. > > g. > ___ > 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
