On 14.05.2018 09:22, Jagan Teki wrote:
On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt
<sgoldschm...@de.pepperl-fuchs.com> wrote:
+ Marek for the socfpga platform, see below
On 07.12.2017 06:49, Jagan Teki wrote:
On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon
<sgoldschm...@de.pepperl-fuchs.com> wrote:
+ Lukasz (as a reviewer of my patch[1])
On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote:
This is the patch[1] for 4-byte addressing, but I would wonder how can
proceed
operations with 4-byte if we disable during probe.
[1] http://git.denx.de/?p=u-boot-
spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca
OK, so your patch does something different than what I did.
I was trying to keep the change to U-Boot as small as possible, only
fixing this issue I was seeing:
After a soft-reboot where the SPI chip was not reset, it is left in
4-byte addressing mode (linux uses this mode, obviously). Remember
that 4-byte mode is not a permanent setting, so we can enter and
leave it any time we like by issuing a command.
U-Boot uses the Bank Address Register (BAR) for spi flash chips with
more than 16 MByte, so it impclitly assumes that the chip is in
3-byte address mode. As I see it, your patch is worth a discussion
named "should we use 4-byte addressing mode on spi flash chips?".
I do think this is a better alternative than writing BAR! But this
change probably needs discussion and testing.
OK, will review your patch.
Any update here? The last input on this is about five months old! This is
the last patch I need to run my socfpga board from qspi.
I added Marek to the discussion as at least the SoCrates board does not have
a reset connected to the qspi chip and needs this as well. Note that the
system boot rom does not have a problem with the chip being in 4-byte mode
but SPL fails to load U-Boot from qspi.
Does Linux do this stuff? say my flash in 4-byte and flashed SPL and rebooted.
Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function
'set_4byte'. I'm using 4.9 where they don't have support for 4 byte
opcodes (which is why I'm seeing this bug after all). OK, this is not
the latest kernel, but it's LTS, so I think U-Boot should handle this
Kernel.
What happens in Linux (4.9) is that depending on the flash size, 4-byte
mode is *always* enabled. And it stays enabled after soft reboot. So
consequently, we have to *always* disable it in U-Boot.
In newer versions, they still use 4-byte mode if the flash chip does not
support 4-byte opcodes. I suppose that would fix it for me, too, but I'm
stuck with LTS for now.
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
