On 30.05.2018 13:27, Marek Vasut wrote:
On 05/30/2018 01:25 PM, Jagan Teki wrote:
On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt
<sgoldschm...@de.pepperl-fuchs.com> wrote:
On 30.05.2018 07:10, Jagan Teki wrote:
On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt
<sgoldschm...@de.pepperl-fuchs.com> wrote:
Hi Jagan,
On 21.05.2018 17:09, Jagan Teki wrote:
Hi Simon,
On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt
<sgoldschm...@de.pepperl-fuchs.com> wrote:
On 14.05.2018 09:47, Simon Goldschmidt wrote:
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.
Do you need any more information here? I'd really love to get this into
2018.07, finally. As I said before, this is the last patch missing for
socfpga cyclone5 running from qspi.
The point I'm not clear is we don't have 4-byte addressing (we are
using Bank addressing for > 16MiB) so how come we disable 4-byte
addressing for the sake of other software blocks enabled it? It's like
a hack to me.
I understand your point. However, there *are* SPI chips without a reset
line. And if linux brings them into 4-byte address mode and then the system
gets a warm reset e.g. by the watchdog, where do you suggest to set the chip
back to 3-byte address mode?
What are those chips?
For example the EPCQ256N mounted on the EBV Socrates board (Cyclone V SoC),
see this doc, pinout is in chapter 1.11.2:
https://www.altera.com/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf
what if we have 4-byte addressing mode in
U-Boot, we completely operate these into 3-byte mode by disabling
4-byte mode?
Ehrm, we don't have 4-byte addressing mode in U-Boot. That's the problem. If
we would, we would surely execute the opcode I have added and explicitly set
the device into 4-byte mode. That would solve the problem.
I'm not sure I understand this, how should 4-byte addressing solve the
problem? you claimed in patch that bootrom would need 3-byte
addressing during warm reset ie what the problem is all about right?
what if u-boot operates in 4-bytes and trigger watchdog, should rom
boots from 4-byte addressing.
IMO his board needs a SPI NOR reset, otherwise he will always have
reliability problems with booting. There will always be cornercases
where the CPU reboots and SPI NOR is left in some crappy state and the
machine will just hang. If you screw up the reset routing, your hardware
is DOOMED and there's no fixing it in software.
That said, the 3byte addressing mode in U-Boot is crap too and should've
been fixed since forever by importing the Linux SPI NOR stack.
So isn't that porting in progress? I haven't followed the ML for that
long though, so I really can't tell what's going on here :-)
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
