On Tue, Jan 08, 2019 at 11:54:32PM +0530, Jagan Teki wrote: > On Thu, Jan 3, 2019 at 9:33 PM Zoltan HERPAI <wigy...@uid0.hu> wrote: > > > > Hi Jagan, Adam, > > > > On Thu, 3 Jan 2019, Jagan Teki wrote: > > > > > On Thu, Jan 3, 2019 at 6:57 PM Zoltan HERPAI <wigy...@uid0.hu> wrote: > > >> > > >> Hi all, > > >> > > >> The DTS resync between 2018.09 and 2018.11 seems to have broken the MMC > > >> support for the Linksprite pcDuino (A10) and pcDuino v3 (A20) boards. > > >> The resync happened in b9d59d0 [1] and 3c92cca [2], after which u-boot > > >> doesn't recognize the MMC controller and freezes the board (exactly the > > >> same happens on the v3 board). > > >> > > >> ---- CUT HERE ---- > > >> U-Boot SPL 2018.11 (Dec 31 2018 - 14:36:52 +0000) > > >> DRAM: 1024 MiB > > >> CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 > > >> Trying to boot from MMC1 > > >> > > >> > > >> U-Boot 2018.11 (Dec 31 2018 - 14:36:52 +0000) Allwinner Technology > > >> > > >> CPU: Allwinner A10 (SUN4I) > > >> Model: LinkSprite pcDuino > > >> I2C: ready > > >> DRAM: 1 GiB > > >> MMC: > > >> ---- CUT HERE ---- > > >> > > >> Reverting these commits solve the problem and the boards boot correctly. > > >> Initially I thought this might be due to removing the > > >> mmc0_cd_pin_reference_design (syncing that from the kernel into u-boot), > > >> which was discussed here [3] and was considered as a move that might > > >> break MMC on some boards, but re-adding that reference pin only in the > > >> pcduino DTSes did not resolve the freeze. > > >> > > >> Questions: > > >> - A similar board - where the reference pin is used for CD - is the > > >> Cubieboard 2. Can someone test 2018.11 on it to see if it freezes as > > >> well? Out of A20, I have a Bananapro, but that's using a non-reference > > >> pin for CD, and boots fine. > > > > > > A10, enable DM_MMC so it can effect DT. or enable CONFIG_MMC0_CD_PIN="PH1" > > > > > > Added Adam, (who actually tested DM_MMC on A10) > > > > I tested with "either" and "both", neither worked - see below. Along with > > CONFIG_DM_MMC, I've also enabled CONFIG_DM_DEBUG to see what's happening - > > here is the output: > > > > [...] > > MMC: uclass_find_device_by_seq: 0 0 > > - -1 -1 'mmc@1c0f000' > > - not found > > uclass_find_device_by_seq: 1 0 > > - -1 -1 'mmc@1c0f000' > > - not found > > uclass_find_device_by_seq: 0 -1 > > uclass_find_device_by_seq: 0 0 > > - -1 -1 'mmc@1c0f000' > > - not found > > Entering sunxi_mmc_probe > > ofnode_read_u32: bus-width: 0x4 (4) > > sunxi_mmc: priv->reg: 1c0f000 > > sunxi_mmc: priv->mclkreg: 1c20000 > > I'm looking for gate and clk register values, print at the end of probe > 1c20000 + 0x60 > 1c20000 + 0x88
With current master: sunxi_mmc_probe: gate_reg: 0x4141 sunxi_mmc_probe: clk_reg: 0x0 With 3c92cca3cda0d72c11c41bc0b07edcff127cf194 reverted: sunxi_mmc_probe: gate_reg: 0x4141 sunxi_mmc_probe: clk_reg: 0x80000000 > > > ofnode_read_bool: cd-inverted: false > > -------- > > > > > > > A20, can boot as it is, it doesn't effect mmc node on DT, since DM_MMC > > > is not available. > > > > > >> - There are some clock-related changes in this DTS resync, however I > > >> have less than optimal experience with clocks. Can someone help check if > > >> these changes might cause the issue? > > > > > > OK, better dump the clock reg value at the end of sunxi_mmc_probe > > > > For A20 it looks like this: > > > > -------- > > MMC: Entering sunxi_mmc_probe > > sunxi_mmc: priv->reg: 1c0f000 > > sunxi_mmc: priv->mclkreg: 1c20000 > > Same for here? > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
