From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Fri, 27 Nov 2015 07:32:47 +0100 Subject: [U-Boot] [PATCH v7 00/34] sf: MTD support In-Reply-To: <5657D594.1010204@denx.de> References: <1448539458-14306-1-git-send-email-jteki@openedev.com> <5656FBC5.6@denx.de> <56570362.7070808@denx.de> <565745BE.7020309@denx.de> <56574B9F.6090404@denx.de> <5657D594.1010204@denx.de> Message-ID: <5657F90F.9090802@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, On 27.11.2015 05:01, Stefan Roese wrote: > Hi Simon, > > On 26.11.2015 19:22, Simon Glass wrote: >> Hi Stefan, >> >> On 26 November 2015 at 10:12, Stefan Roese wrote: >>> Hi Simon, >>> >>> On 26.11.2015 18:55, Simon Glass wrote: >>>> Hi Stefan, >>>> >>>> On 26 November 2015 at 09:47, Stefan Roese wrote: >>>>> Hi Simon, >>>>> >>>>> On 26.11.2015 17:48, Simon Glass wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>> Yes. I'm trying to enable SPL_DM on MVEBU. And this with >>>>>>> DM_SPI and DM_SPI_FLASH enabled as well. I've the kirkwood >>>>>>> SPI driver ported to DM here for this (patches will follow). >>>>>>> >>>>>>>> what kind of issue? >>>>>>>> is it failed to probe device or something? >>>>>>> >>>>>>> >>>>>>> Here the log (with some debug() enabled): >>>>>>> >>>>>>> ----------<------------------------------- >>>>>>> uclass_find_device_by_seq: 0 -1 >>>>>>> uclass_find_device_by_seq: 0 0 >>>>>>> - -1 -1 >>>>>>> - not found >>>>>>> bind node serial at 12000 >>>>>>> - found match at 'ns16550_serial' >>>>>>> Bound device serial at 12000 to root_driver >>>>>>> uclass_find_device_by_seq: 0 -1 >>>>>>> uclass_find_device_by_seq: 0 0 >>>>>>> - -1 -1 >>>>>>> - not found >>>>>>> >>>>>>> U-Boot SPL 2016.01-rc1-00267-gdb3362c-dirty (Nov 26 2015 - 14:00:16) >>>>>>> High speed PHY - Version: 2.0 >>>>>>> Detected Device ID 6828 >>>>>>> board SerDes lanes topology details: >>>>>>> | Lane # | Speed | Type | >>>>>>> -------------------------------- >>>>>>> | 0 | 5 | PCIe0 | >>>>>>> | 1 | 3 | SATA0 | >>>>>>> | 2 | 3 | SATA1 | >>>>>>> | 3 | 3 | SATA3 | >>>>>>> | 4 | 3 | SATA2 | >>>>>>> | 5 | 5 | USB3 HOST1 | >>>>>>> -------------------------------- >>>>>>> PCIe, Idx 0: detected no link >>>>>>> High speed PHY - Ended Successfully >>>>>>> DDR3 Training Sequence - Ver TIP-1.29.0 >>>>>>> DDR3 Training Sequence - Switching XBAR Window to FastPath Window >>>>>>> DDR3 Training Sequence - Ended Successfully >>>>>>> Trying to boot from SPI >>>>>>> uclass_find_device_by_seq: 0 0 >>>>>>> - not found >>>>>>> uclass_find_device_by_seq: 1 0 >>>>>>> - not found >>>>>>> Invalid bus 0 (err=-19) >>>>>>> SPI probe failed. >>>>>>> SPL: failed to boot from all boot devices >>>>>>> ### ERROR ### Please RESET the board ### >>>>>>> ----------<------------------------------- >>>>>>> >>>>>>> Simon, do you have a clue what's missing here? SPI NOR booting >>>>>>> is working just fine in SPL without SPL_DM enabled on this >>>>>>> platform. AFAICT, I've added the required "u-boot,dm-pre-reloc" >>>>>>> properties to the dts. >>>>>>> >>>>>>>> I will verify the same and >>>>>>>> let you know. >>>>>>> >>>>>>> >>>>>>> How can you verify this if SPI is not working at all for you? Or >>>>>>> did I misunderstand you (see above)? >>>>>> >>>>>> >>>>>> -19 means -ENODEV. I suppose CONFIG_SPL_OF_CONTROL is enabled. >>>>> >>>>> >>>>> Yes. >>>>> >>>>>> You can >>>>>> check the device tree used for SPL in your build directory - >>>>>> spl/u-boot-spl.dtb. >>>>>> >>>>>> From the debugging it looks like you have no SPI flash devices. >>>>> >>>>> >>>>> That is my understanding as well. And I fail to see, where this >>>>> device get added to the list of UCLASS devices. >>>>> >>>>>> You can check chromebook_jerry which uses this feature. See this >>>>>> node: >>>>>> >>>>>> &spi2 { >>>>>> status = "okay"; >>>>>> u-boot,dm-pre-reloc; >>>>>> >>>>>> spi_flash: spiflash at 0 { >>>>>> u-boot,dm-pre-reloc; >>>>>> compatible = "spidev", "spi-flash"; >>>>>> spi-max-frequency = <20000000>; /* Reduce for Dediprog >>>>>> em100 pro */ >>>>>> reg = <0>; >>>>>> }; >>>>>> }; >>>>> >>>>> >>>>> I've checked this now and reworked the dts a bit. But still no >>>>> cigar. The debug output is identical to the last one. >>>>> >>>>> I've attached the dts / dtb and the current .config. It would >>>>> be great if you could take a quick look at it to see, what I >>>>> am missing here. >>>> >>>> CONFIG_SPL_OF_TRANSLATE should be defined I think, >>> >>> Yes. But this does not explain why this device is not found at all. >>> This would only result in an incorrect base-address. And this works >>> since the serial node seems to be okay (DM in SPL here as well). >>> >>>> and also you need a >>>> u-boot,dm-pre-reloc in the soc {} node, otherwise the properties there >>>> will not appear. >>> >>> Its already there in the dtsi file. I've added it again in this >>> dts file as well. >>> >>>> >>>> You can call dm_dump_all() in SPL, and dm_dump_uclass(), to see what >>>> devices are present. >>> >>> Ah, this is helpful. Thanks. Here the output for your profound >>> inspection: ;) >>> >>> Trying to boot from SPI >>> uclass_find_device_by_seq: 0 0 >>> - not found >>> uclass_find_device_by_seq: 1 0 >>> - not found >>> Invalid bus 0 (err=-19) >>> SPI probe failed. >>> Class Probed Name >>> ---------------------------------------- >>> root [ + ] root_driver >>> serial [ + ] `-- serial at 12000 >> >> That shows that the SPI device or driver is not being found. I don't >> see a driver for 'marvell,armada-380-spi' in the tree anyway - is it >> your own private patches? > > Yes, this is in my local tree - waiting for this issue to get > resolved before sending to the list. > >> If you add DEBUG to drivers/core/lists.c you may be able to see why it >> is not finding a driver for that node. > > "#define DEBUG" is already set in lists.c. > > I have the notion that drivers are not added "automatically" to > the lists. My debugging has shown that for example the serial > driver is only added to the list after this call in serial-uclass.c: > > lists_bind_fdt(gd->dm_root, blob, node, &dev) > > Before this call, I have this output from dm_dump_all(): > > Class Probed Name > ---------------------------------------- > root [ + ] root_driver > > Then, calling lists_bind_fdt() results in this debug output: > > bind node serial at 12000 > - found match at 'ns16550_serial' > Bound device serial at 12000 to root_driver > > And now, dm_dump_all() shows this directly after the lists_bind_fdt(): > > Class Probed Name > ---------------------------------------- > root [ + ] root_driver > serial [ ] `-- serial at 12000 > > > Seems that drivers need to get actively "binded" to the lists. > And this is not happening for the SPI driver. > > What am I missing? I finally found it. I had CONFIG_SPL_SIMPLE_BUS disabled. So all devices behind this "simple-bus" where not visible to DM. Now this looks much better. Thanks, Stefan