[RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

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 ...
   <DEAD>
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: <https://lists.denx.de/pipermail/u-boot/attachments/20200121/97f08b45/attachment.bin>