[U-Boot] git bisect failed
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@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 92c2dc0f64f3115c77577f110eac6753dada9b15 0a5051ce6ebd5f6fad58fd50d6922493d8447f14 f1ef2b62339526df3b921bcfefd174ce76d4c624 e3a4facdfc07179ebe017a07b8de6224a935a9f3 f494e0a1847d74e68c460c90253836ea21c431ac 2f665945b39a9972260cbcf60d5e7f2a60587f5e d660b409dc3658087ce15e7d50ed007f1cfa09e8 be16aba5ce8d04b8ca0ebd5ac95d878064e44bd8 c79cba37b3b42cf8fbd71babcd8998867f76fead 3eb3e72a3f66db140dabd66b553380c19b2035d4 87f13aa00d0279fcc96530404c3a104eb4cb1672 93d3232d9607669f33a34d3a552b24e1d727413b f9860cf081efdf32c8a01b9fc271fe55e2a79f8d 110bdee00f70ba2cae90a8db39e8d3e854141a56 97d5e9d149ca910e1bd20d06a13b9e9cceb0e502 5e74934d407d2aabe5c4283b4394969025c643e3 64147e564cf43bb33b68766053960002bc0784dd 1d5c20154f0797e9a79fd0b39a9ae8a8801f6a51 df3b23ae3a7bb0627d595e6139ea43655d5acaa4 248a0488bfbb2eb16dee408a976d5f4b5546bb51 726ac8e4c505f086c1decd5263068373254ee60a cccee18918a9bcc1b34ddcd33f219a4ed26fc690 ca05ee9d43297cef9bb9ec74973d58586a6e4321 dba1697057abed60bcb46ff724dad9f3e090c566 b0928da648d440778512ddd81e690717239b8f1f ed36323f6d217050f82a2200475959b8557a47e4 2c3dc792b6df16970077c0d64085e29f1f85d4c8 a03bdaa1408be4e8b6adfc8577a0ceac3ebc51e5 535aad29f2a0881f66a0efdb3d467d0910d5e41e e5a504eb3d8cbc33199dac61a07d16ddd3c1c7f9 5dff844d7ff1704534905db9beb888f5552adb84 129acd4c75f85bdb7f1267fe5f1187e0fc37d221 07b342783a11bc56c38207006b5ad9d70ca3c863 8969ea3e9f2db04a6b36758972b708837786a5a5 b84505210367d152a456a2adeba90e13626ad104 214b3f311f0c1ac4c8f68e45133fc3547c76d8d1 ab7cb4eefa33b79834f0a000bcb365e98c14c693 a4277200a2253fda49342aa65800d27e61276170 bdc7dc4595646da8774f53a2c4f5a7599b0a5f16 c7eae7fcb11bc7dab519fca8d8902f1fbc5c3c76 e5bf9878ea743564bcc7a15a79654fe06731a1e2 593cbd93f33c38ca3ee9db34b5657a15d2437902 f80d6472b47e73e35e4eaed6fc56ce5df2c82cdb 2c2277f15cbaa9533ef8aead7328c3f605251147 8aeb893a8ed97bac679149386cec53b275be3715 d1b5ed075311f143926dd916edb59436267eb396 8bfa301b0a30f57888d2117767b23f168760bc40 c0aebb3382133c99bc458d96b562703dae4ae928 039b77396abb0ed78af34dadbd0786dfaf0e6aa9 40f8dec54d7803975aed1c88327002c95ea99908 7172de33b0cc0a44713fd4fbbb61fd1fada17341 5273aa3834ec68616e173ceac91cdcf60dba2868 bf9b86dc47988a404964c97c74e541a129719f9c f43b4356a794be647011132f4f2dc970a29a9dd5 0299046e5b4eec6c79927324deab857db1689e92 08df4a21c7d580770cabd7ba62591da035d9a545 92f7fed4f738149121c779fe1dda857585bdeccf 07c4eea4846cde938c4b0d8c1ddee95d373693ed bb5783224b9b12eecf406761f82e3de2a2ca9dae be9f643ae6aa9044c60fe80e3a2c10be8371c692 c032174f8218496a7768e4a27d1eb25b7e6f7a4d 1de271b487d60c613568ad61fc005ff850f2ed71 4b0abf9f3c024225987ec92ea9ae9e8a1ac5950d 75f698e51c7e40048e4d96fdaaaebeaefc945538 d9c68b1444acb383684636eb856fd7e4cec04129 1d71efbb0345ff3a8ac45e62bef36813abe1703e 31969b8993ee00015b7ac0f979d601299158fc6e 38e0e15372f9f463ab8dd30d21a46cb477e80dd4 845034e6b217d5ff73de03213ede9b17646a91b1 7f368553fcada0b38e8a096fcba4fcd64e0d2020 88e34e5ff76bffa7d56b1d04e0bd2627ee5b584d e211c12e773881f6bef60143df4764402a56de34 e628c8f75de952031f7b9fb9ae465a2a99d4c7f8 155fa9af95ac5be857a7327e7a968a296e60d4c8 363fb32aca268701a0918d67099fb344194f1746 5894ca007d217a2fa845facfbb62c6512396a145 5b8388a827c002c6c5e8da76bd99b66f1f26e92c 01d2aaf61ba7d532dee7002a2049d2b972992122 1b35721f61207c5f3cdf924be3bb64e0ad12887c 66cba041fe8fe4cdc3d8252974021257e736572a d087e0e26293a34752a6279da85f94a97084686c 0fb63aa63c35888dface83b44c1401be097277eb 47d3debe1ab8315dc9ade22279e02f60eceda25b 6dd0e7c00bfa5ce861a72b8e4a3ef9e787306125 45e60c25b54f0443265ee49909c70af90d5cbad9 8ca21cbea2671bad315cc93ab636a95d95bac058 cae025aab3e8ea8ad455cce8b0e4647401cdd091 1e3d64031608d668509b6fe0825f7708bb6b6a0d 59990bf0eaa12b123759cb0485f38e156103e93c 692c223518023b47579fbf1142a8f639cbedb5b0 65ae9523d9a5868075be40ef2582c75190cee6af 91cbd792c46c916ef196c5b7cd16ff592d2f3632 983a2749e2fdc459b2f44e82241a5c314ddbcdf6 0f88a5a98eb9d8d5158b074a127a4bf8d4ce8610 1454ba8e56d88a8b95ac8050cde2c07c651cd0ae 7798e2285fda17aa2268cbe18498678cf857905f bf1a86fca0111067021f3d263242767d3709d7be 4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01 6b1978f8a14fc2f53715f65827e98d607cc21e63 c19a8bc5711ec63e905ef91f045a1489f0aa3cb0 e7b14e9ab0ceef3068722007e7396f89f4ede9c2 4b19b7448e63bab8af17abbb30acff00d8f0dc99 We cannot bisect more!
I had to skip steps in the bisect run as the board support was not existing.
Any hints?
greets -- Christian Gmeiner, MSc
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@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
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.
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 =>
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
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
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
participants (5)
-
Anatolij Gustschin -
Christian Gmeiner -
Fabio Estevam -
Stefano Babic -
Tom Rini