On Sat, 2020-03-28 at 01:44 +0800, Chen-Yu Tsai wrote: > Hi, > > On Fri, Mar 27, 2020 at 11:07 PM Kurt Miller <k...@intricatesoftware.com> > wrote: > > > > > > On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote: > > > > > > From: Chen-Yu Tsai <w...@csie.org> > > > > > > Hi everyone, > > > > > > This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC > > > single board computer. > > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit > > > card size development board based on the Rockchip RK3328 SoC, with: > > > > > > - 1/2/4 GB DDR4 DRAM > > > - eMMC connector for optional module > > > - micro SD card slot > > > - 1 x USB 3.0 host port > > > - 2 x USB 2.0 host port > > > - 1 x USB 2.0 OTG port > > > - HDMI video output > > > - TRRS connector with audio and composite video output > > > - gigabit Ethernet > > > - consumer IR receiver > > > - debug UART pins > > > > > > Originally I started with Loic's patches, and syncing the device tree > > > files from Linux. That didn't get very far, with SPL failing to detect > > > the SD card. Examining the schematics and internal state of GRF and > > > GPIOs, I realized that the logic for the SD card power enable switch > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin > > > would use. Instead, directly using the GPIO is required. > > > > > > Thus this series creates a special target for this board to handle > > > muxing this specific pin to GPIO state. The GPIO is left in input mode, > > > letting the external pull-down work its magic. > > > > > > Along the way, there are some clean-ups of existing dts files, moving > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync > > > from Linux. Only boards already existing in U-boot are synced. DT > > > binding header files are synced separately as there is already one > > > patch floating around. The DT sync also includes clean-up changes only > > > recently posted, and likely won't make it in for at least a few weeks. > > > > > > Please have a look, and test if possible. I cc-ed a couple people that > > > showed interest in this board on mailing lists recently. > > > > > Thank you for updating the dts for rk3328. I have Rock64 v2 and v3 > > boards and have tested your patchset with OpenBSD-current. The v2 board > > is working and I have not noticed any regressions. The v3 board prior > > to your patchset was not booting and continues to not boot. > > > > U-Boot TPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24) > > LPDDR3, 800MHz > > BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB > > Trying to boot from BOOTROM > > Returning to boot ROM... > > > > U-Boot SPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24 > > -0400) > > Trying to boot from MMC1 > > Card did not respond to voltage select! > > spl: mmc init failed with error: -95 > > Trying to boot from MMC2 > > Card did not respond to voltage select! > > spl: mmc init failed with error: -95 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > The Rock64 v3 board issues are unrelated to your patch set, but I > > believe it needs a similar approach as ROC-RK3328-CC. Here is some > > info previously posted regarding this: > > > > https://marc.info/?t=155751506500001&r=1&w=2 > So based on the changes from Pine64, it looks like v3 follows a similar > design as the ROC-RK3328-CC, that is use the SDMMC0_PWREN pin to control > power to the SD card. On the Rock64 v3, there's no external pull-down, > but the internal pull-down might be enough... > > You could try setting the target to ROC-RK3328-CC through menuconfig > after you use the defconfig for rock64 and see if that works for you. >
Yes, that works for both the v2 and v3 boards. Thank you. Would you be able to create a patch 7 in your series to apply this approch to the rock64? Regards, -Kurt