sandbox: CONFIG_SYS_RELOC_GD_ENV_ADDR?

[Tom Rini]

On Fri, Feb 14, 2020 at 12:16:33PM -0700, Simon Glass wrote:
> Hi AKASHI,
> 
> On Thu, 13 Feb 2020 at 18:39, AKASHI Takahiro
> <takahiro.akashi at linaro.org> wrote:
> >
> > Tom, Simon,
> >
> > Is CONFIG_SYS_RELOC_GD_ENV_ADDR really needed on sandbox?
> >
> > When I try to have a variable environment on emulated SPI flash,
> > the U-Boot binary always crashes: (NOTE: assuming CONFIG_ENV_ADDR == 0)
> >     $ dd if=/dev/zero of=./spi.bin bs=1M count=4
> >     $ u-boot -T
> >     U-Boot 2020.04-rc2-00015-gc9afef2b1938-dirty (Feb 14 2020 - 10:24:59 +0900)
> >
> >     Model: sandbox
> >     DRAM:  128 MiB
> >     WDT:   Started with servicing (60s timeout)
> >     MMC:   mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> >     Loading Environment from SPI Flash... SF: Detected m25p16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB
> >     *** Warning - bad CRC, using default environment
> >
> >     Segmentation fault (core dumped)
> >
> > If this configuration is disabled, panic doesn't happen.
> > I think that it should be turned off in any sandbox*_defconfig.
> >
> > In addition, please update
> > - doc/arch/sandbox.rst
> > - doc/SPI/README.sandbox-spi
> > Both two still mention already-removed command line option, --spi_sf.
> > It is confusing.
> 
> I'm not an expert on this, but I can't see any use for this in
> sandbox. One problem might be that it should be using map_sysmem()
> instead of a cast.

If the option needs to be dropped for things to work, we should just
drop it.  When migrating some of the logic here in to CONFIG symbols I
did match, I'm pretty certain, the previous behavior.  But there's been
a few other cases I got backwards, so this could have been another.  So
long as 'make tests' is happy after the change, we should just do it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200214/42a2ee13/attachment.sig>