* [U-Boot] git bisect failed
2014-10-21 11:43 [U-Boot] git bisect failed Christian Gmeiner
@ 2014-10-21 11:58 ` Stefano Babic
2014-10-21 16:39 ` Tom Rini
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: Stefano Babic @ 2014-10-21 11:58 UTC (permalink / raw)
To: u-boot
Hi Christian,
On 21/10/2014 13:43, Christian Gmeiner wrote:
> Hi all.
>
> Finally I got basic board support for OT1200 into upstream, but the
> last released
> version fails to detect SPI flash (read only ff's).
>
> The good one is commit 39d0973300b83c08f3f5047245ebf1de883b31f2
> and the bad one is c43fd23cf619856b0763a64a6a3bcf3663058c49
>
> [christian at chgm-pc u-boot]$ git bisect good
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
> 540d434aa420bc056326f0f02135bb17e46be5b1
> 783e6a72b8278d59854ced41a4696c9a14abbb0b
> Any hints?
My suggestion is to check changes in drivers/spi/mxc_spi.c and
drivers/mtd/spi/ that were merged after you test your board. If only
ff's are read, maybe the chip select is not driven - have you checked it ?
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 7+ messages in thread* [U-Boot] git bisect failed
2014-10-21 11:43 [U-Boot] git bisect failed Christian Gmeiner
2014-10-21 11:58 ` Stefano Babic
@ 2014-10-21 16:39 ` Tom Rini
2014-10-21 16:47 ` Fabio Estevam
2014-10-21 19:53 ` Anatolij Gustschin
3 siblings, 0 replies; 7+ messages in thread
From: Tom Rini @ 2014-10-21 16:39 UTC (permalink / raw)
To: u-boot
On Tue, Oct 21, 2014 at 01:43:36PM +0200, Christian Gmeiner wrote:
> Hi all.
>
> Finally I got basic board support for OT1200 into upstream, but the
> last released
> version fails to detect SPI flash (read only ff's).
[snip]
> I had to skip steps in the bisect run as the board support was
> not existing.
>
> Any hints?
What I've done in the past is make a local patch that adds a given board
so that instead of skipping I apply that local patch, build, test,
un-patch and git bisect good/bad, and repeat.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141021/af6b1245/attachment.pgp>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] git bisect failed
2014-10-21 11:43 [U-Boot] git bisect failed Christian Gmeiner
2014-10-21 11:58 ` Stefano Babic
2014-10-21 16:39 ` Tom Rini
@ 2014-10-21 16:47 ` Fabio Estevam
2014-10-22 0:22 ` Fabio Estevam
2014-10-21 19:53 ` Anatolij Gustschin
3 siblings, 1 reply; 7+ messages in thread
From: Fabio Estevam @ 2014-10-21 16:47 UTC (permalink / raw)
To: u-boot
Hi Christian,
On Tue, Oct 21, 2014 at 9:43 AM, Christian Gmeiner
<christian.gmeiner@gmail.com> wrote:
> Hi all.
>
> Finally I got basic board support for OT1200 into upstream, but the
> last released
> version fails to detect SPI flash (read only ff's).
I can confirm that 2014.10 has a SPI probe issue on a mx6qsabresd as well:
U-Boot 2014.10 (Oct 21 2014 - 14:45:04)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Display: HDMI (1024x768)
In: serial
Out: serial
Err: serial
PMIC: PFUZE100 ID=0x10
Net: FEC [PRIME]
Hit any key to stop autoboot: 0
=> sf probe
SF: Unsupported flash IDs: manuf 00, jedec 0000, ext_jedec 0000
Failed to initialize SPI flash at 0:0
=>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] git bisect failed
2014-10-21 16:47 ` Fabio Estevam
@ 2014-10-22 0:22 ` Fabio Estevam
0 siblings, 0 replies; 7+ messages in thread
From: Fabio Estevam @ 2014-10-22 0:22 UTC (permalink / raw)
To: u-boot
On Tue, Oct 21, 2014 at 2:47 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Christian,
>
> On Tue, Oct 21, 2014 at 9:43 AM, Christian Gmeiner
> <christian.gmeiner@gmail.com> wrote:
>> Hi all.
>>
>> Finally I got basic board support for OT1200 into upstream, but the
>> last released
>> version fails to detect SPI flash (read only ff's).
>
> I can confirm that 2014.10 has a SPI probe issue on a mx6qsabresd as well:
Ops, I was testing on wrong board (one which has no SPI flash populated :-)
Tested on another mx6qsabresd and it detectes the SPI correctly:
=> sf probe
SF: Detected M25P32 with page size 256 Bytes, erase size 64 KiB, total 4 MiB
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] git bisect failed
2014-10-21 11:43 [U-Boot] git bisect failed Christian Gmeiner
` (2 preceding siblings ...)
2014-10-21 16:47 ` Fabio Estevam
@ 2014-10-21 19:53 ` Anatolij Gustschin
2014-10-22 9:14 ` Christian Gmeiner
3 siblings, 1 reply; 7+ messages in thread
From: Anatolij Gustschin @ 2014-10-21 19:53 UTC (permalink / raw)
To: u-boot
Hi Christian,
On Tue, 21 Oct 2014 13:43:36 +0200
Christian Gmeiner <christian.gmeiner@gmail.com> wrote:
> Hi all.
>
> Finally I got basic board support for OT1200 into upstream, but the
> last released
> version fails to detect SPI flash (read only ff's).
>
> The good one is commit 39d0973300b83c08f3f5047245ebf1de883b31f2
> and the bad one is c43fd23cf619856b0763a64a6a3bcf3663058c49
$ git log 39d097330..c43fd23c drivers/spi/mxc_spi.c
commit 155fa9af95ac5be857a7327e7a968a296e60d4c8
Author: Nikita Kiryanov <nikita@compulab.co.il>
Date: Wed Aug 20 15:08:50 2014 +0300
spi: mxc: fix sf probe when using mxc_spi
MXC SPI driver has a feature whereas a GPIO line can be used to force CS high
across multiple transactions. This is set up by embedding the GPIO information
in the CS value:
cs = (cs | gpio << 8)
This merge of cs and gpio data into one value breaks the sf probe command:
if the use of gpio is required, invoking "sf probe <cs>" will not work, because
the CS argument doesn't have the GPIO information in it. Instead, the user must
use "sf probe <cs | gpio << 8>". For example, if bank 2 gpio 30 is used to force
cs high on cs 0, bus 0, then instead of typing "sf probe 0" the user now must
type "sf probe 15872".
This is inconsistent with the description of the sf probe command, and forces
the user to be aware of implementaiton details.
Fix this by introducing a new board function: board_spi_cs_gpio(), which will
accept a naked CS value, and provide the driver with the relevant GPIO, if one
is necessary.
Cc: Eric Nelson <eric.nelson@boundarydevices.com>
Cc: Eric Benard <eric@eukrea.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Does it work if you revert 155fa9af ?
Thanks,
Anatolij
^ permalink raw reply [flat|nested] 7+ messages in thread* [U-Boot] git bisect failed
2014-10-21 19:53 ` Anatolij Gustschin
@ 2014-10-22 9:14 ` Christian Gmeiner
0 siblings, 0 replies; 7+ messages in thread
From: Christian Gmeiner @ 2014-10-22 9:14 UTC (permalink / raw)
To: u-boot
Hi Anatolij
2014-10-21 21:53 GMT+02:00 Anatolij Gustschin <agust@denx.de>:
> Hi Christian,
>
> On Tue, 21 Oct 2014 13:43:36 +0200
> Christian Gmeiner <christian.gmeiner@gmail.com> wrote:
>
>> Hi all.
>>
>> Finally I got basic board support for OT1200 into upstream, but the
>> last released
>> version fails to detect SPI flash (read only ff's).
>>
>> The good one is commit 39d0973300b83c08f3f5047245ebf1de883b31f2
>> and the bad one is c43fd23cf619856b0763a64a6a3bcf3663058c49
>
> $ git log 39d097330..c43fd23c drivers/spi/mxc_spi.c
An other git command detail I have learned today - thanks!
> commit 155fa9af95ac5be857a7327e7a968a296e60d4c8
> Author: Nikita Kiryanov <nikita@compulab.co.il>
> Date: Wed Aug 20 15:08:50 2014 +0300
>
> spi: mxc: fix sf probe when using mxc_spi
>
> MXC SPI driver has a feature whereas a GPIO line can be used to force CS high
> across multiple transactions. This is set up by embedding the GPIO information
> in the CS value:
>
> cs = (cs | gpio << 8)
>
> This merge of cs and gpio data into one value breaks the sf probe command:
> if the use of gpio is required, invoking "sf probe <cs>" will not work, because
> the CS argument doesn't have the GPIO information in it. Instead, the user must
> use "sf probe <cs | gpio << 8>". For example, if bank 2 gpio 30 is used to force
> cs high on cs 0, bus 0, then instead of typing "sf probe 0" the user now must
> type "sf probe 15872".
>
> This is inconsistent with the description of the sf probe command, and forces
> the user to be aware of implementaiton details.
>
> Fix this by introducing a new board function: board_spi_cs_gpio(), which will
> accept a naked CS value, and provide the driver with the relevant GPIO, if one
> is necessary.
>
> Cc: Eric Nelson <eric.nelson@boundarydevices.com>
> Cc: Eric Benard <eric@eukrea.com>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Tom Rini <trini@ti.com>
> Cc: Marek Vasut <marex@denx.de>
> Reviewed-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
> Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
>
> Does it work if you revert 155fa9af ?
>
That is the "bad" commit - I will send a patch to fix it at board level.
Thanks a lot!
--
Christian Gmeiner, MSc
https://soundcloud.com/christian-gmeiner
^ permalink raw reply [flat|nested] 7+ messages in thread