[PATCH] Revert "spi: spi-uclass: Add support to manually relocate spi memory ops"

[Dennis Gilmore]

On Fri, Jul 23, 2021 at 10:25 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Jul 23, 2021 at 09:46:44PM -0500, Dennis Gilmore wrote:
>
> > removing the header is not sufficient to have the boards booting from SPI.
> >
> > U-Boot TPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57)
> > Channel 0: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > Channel 1: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > 256B stride
> > lpddr4_set_rate: change freq to 400000000 mhz 0, 1
> > lpddr4_set_rate: change freq to 800000000 mhz 1, 0
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57 -0500)
> > Trying to boot from SPI
> >
> > At this point u-boot hangs, with the patch reverted I get the following
> > U-Boot TPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51)
> > Channel 0: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > Channel 1: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > 256B stride
> > lpddr4_set_rate: change freq to 400000000 mhz 0, 1
> > lpddr4_set_rate: change freq to 800000000 mhz 1, 0
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 -0500)
> > Trying to boot from SPI
> >
> >
> > U-Boot 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 -0500)
> >
> > SoC: Rockchip rk3399
> > Reset cause: RST
> > Model: Kobol Helios64
> > Revision: 0.0 - Unknown
> > DRAM:  3.9 GiB
> > PMIC:  RK808
> > MMC:   mmc at fe320000: 1, mmc at fe330000: 0
> > Loading Environment from SPIFlash... SF: Detected w25q128 with page
> > size 256 Bytes, erase size 4 KiB, total 16 MiB
> > *** Warning - bad CRC, using default environment
> >
> > In:    serial at ff1a0000
> > Out:   serial at ff1a0000
> > Err:   serial at ff1a0000
> > Model: Kobol Helios64
> > Revision: UNKNOWN
> > Net:   dw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > busNo ethernet found.
> >
> > starting USB...
> > Bus usb at fe900000: usb maximum-speed not found
> > Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb at fe900000 for devices... 2 USB Device(s) found
> >        scanning usb for storage devices... 0 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > switch to partitions #0, OK
> > mmc0(part 0) is current device
> > ** No partition table - mmc 0 **
> > Couldn't find partition mmc 0:1
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Scanning disk mmc at fe320000.blk...
> > Scanning disk mmc at fe330000.blk...
> > ** Unrecognized filesystem type **
> > Found 5 disks
> > dw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > busdw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > busLoading Boot0000 'Fedora' failed
> > EFI boot manager: Cannot load any image
> > Found EFI removable media binary efi/boot/bootaa64.efi
>
> Is LTO on, on these platforms?  That code in question really should not
> be enabled, at all.  Like, if you toss an #error in that section of
> code, it should still build.  It does, right?

It does still build if I put a #error in the middle of it

$ grep LTO .config
CONFIG_ARCH_SUPPORTS_LTO=y
# CONFIG_LTO is not set


LTO is not on


> --
> Tom