From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Condarelli Date: Tue, 21 Jan 2020 12:27:50 +0100 Subject: [RFC] Vocore2 MMC needs clock patches In-Reply-To: <1579576318.26858.29.camel@mcddlt001> References: <4a029fae-c5f8-bcfa-14e4-c5b636351e32@mclink.it> <1579576318.26858.29.camel@mcddlt001> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Thanks Weijie, I made the changes You suggested. I have also seen You sent a new version of Your patches. Since mine are based on yours I *think* I should suspend sending my VoCore2 patches till Yours are fixed and integrated into master. @Stefan Roese: is this the right course of action? I am happy what I have (pending further test, of course!), but I want this integrated in upstream master, if possible, so I'm prepared to rebase my patches after Weijie ones are in. Any comment welcome. Side Question: Stefan wrote: > Most of this can be done by using the > RAM version now (again). There is no additional RAM booting target now > any more. You can use the normal U-Boot image for this now. Please note > the changes TEXT_BASE here. Its now 0x80200000. This actually seems to work right if I start from my original u-boot (1.1.3, flashed at start of SPI NOR), but it fails if I start from a flashed (at the same location) u-boot-mtmips.bin I *think* this happens because unpacking actually writes u-boot at 0x80200000 and runs it from there, so "load usb 0:1 80200000 u-boot.bin" (or equivalent) will overwrite the running u-boot and the following "go ${fileaddr}" fails:    ## Starting application at 0x80200000 ...    Note that if I load the same version flashed it works ok (presumably because I'm  overwriting with the same content, so no harm done). How can I load in RAM end test a new version once I flash new-style u-boot? I am thinking about relinking at a different address, but I'm unsure. TiA! Regards Mauro Condarelli On 1/21/20 4:11 AM, Weijie Gao wrote: > On Tue, 2020-01-21 at 00:55 +0100, Mauro Condarelli wrote: >> Hi Weijie, >> I attach my, apparently working, port to VoCore2 SoM. >> >> These patchsets are on top of Your 21 patch rewrite of MT7628 board, >> >> While the first patchset is relatively straightforward, but does not include >> MMC handling, to enable it I had to backport from Linux Kernel several >> pieces, essentially clock and interrupt handling. > You are using a superseded patch series (v1) I submitted several months > ago. These patches have already been replaced by v3 and merged into the > mainline. > > * "mtmips-clk-gate" from v1 is replaced by "mediatek,mt7628-clk" and the > function of "mediatek,mt7628-clk" is a superset of "mtmips-clk-gate". > * The node "intc" has no use at all. U-Boot for mips use no interrupts. > * mmc property "hclk" is the gating clock of the SD controller module. > Using <&clk48m> in the v1 patches was a bad idea. I changed it to > <&clkctrl CLK_SDXC> in v3 to make sure its clock will be always > enabled. > * Please move pinctrl properties to your board's dts file. > * pinctrl name "state_uhs" is not used by mtk-sd in U-Boot. MT7628 does > not support UHS. You should remove it. > * vmmc-supply and vqmmc-supply are not used by mtk-sd in U-Boot because > UHS support is not added to the driver. Besides you have assigned > wrong values to them. You should remove it. > >> Those drivers appear written by You. >> I am unsure if this is really needed or if there is some other (perhaps >> cleaner) >> way to enable MMC. >> >> As said this seems to work for me, but I would like to contribute this >> board upstream, in the best possible way. >> >> Please let me know how I should proceed. > I don't have a board with the "sd_iot_mode" pinmux for SDXC, so I can't > tell you why you can't use it with my v3 patches. But I have tested v3 > patches on boards using "sd_router_mode" pinmux and they do work well. > >> Best Regards and Thanks in Advance >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-mips-mtmips-vocore2-add-support-for-MMC-SD.patch Type: text/x-patch Size: 4940 bytes Desc: not available URL: