Initial support for MT7620

[Adrian Chadd]

hiya!

Yes, I think between ray and I we can get your stuff into -HEAD.

The nice thing about the MT7620 change is that it's pretty
non-intrusive and if it works, we can start by committing it soon.

I have Stanislav's changes so far in a github branch:

https://github.com/erikarn/freebsd/tree/local/adrian_mt7620

This includes his mt7620 and mt7621 changes.

I haven't fired it up on the 7620 yet (tonight, i hope!)

My plan here is to get the 7620 support up enough to do ethernet and
then commit it to the rt305x/ tree. Then we can start refactoring out
the CPU model specific pieces into chip_xxxx.[ch] files. The biggest
change between r305x and mt7620 (and then mt7621) is the memory map
stuff, which for now we can easily do with a struct to represent
things and then some ifdefs to choose the right one. That way it's
nice and clean. The other mt7620 changes are very small and easy. The
7621 changes require some startup path changes and uart/uartlite
fiddling.

Hang out on #bsdmips in like 10 hours time; I'll start tinkering then. :)


Thanks,



-adrian


On 16 December 2015 at 05:47, Stanislav Galabov <sgalabov at gmail.com> wrote:
>
>> On Dec 16, 2015, at 14:05, Aleksandr Rybalko <ray at ddteam.net> wrote:
>>
>> On Tue, 15 Dec 2015 16:58:31 +0200
>> Stanislav Galabov <sgalabov at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> After talking with Adrian off list we decided to start work on Mediatek/Ralink more recent SoCs with MT7620 instead of MT7621 (Adrian’s board has MT7620 so it’s easier for him to help with the WiFi parts this way).
>>>
>>> I’ve done a bit today and I got an MT7620A based board to boot to multi user with root filesystem on USB stick.
>>>
>>> If anyone is interested in the patch, it can be found here:
>>> https://www.dropbox.com/s/e880eutzvlms8h7/mt7620_patch.diff?dl=0
>>>
>>> For the moment there is no support for sys/dev/rt (the Ethernet controller) with MT7620. This is going to be left for later.
>>> Next I am planning to work on SPI and PCI so that Adrian can start working on WiFi once I’m done with the SPI part.
>>>
>>> I would appreciate it if someone would jump in and help with the if_rt support - this way we’ll have something working quicker hopefully :-)
>>>
>>> I would also appreciate feedback for the attached patch...
>>>
>>> Best wishes,
>>> Stanislav
>>> _______________________________________________
>>> freebsd-mips at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
>>> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>>
>> Hi Stanislav!
>>
>> There is patch #1 that did my friend, Alexander A. Mityaev.
>> Patch cover to things:
>> 1. enable support of RT5350
>> 2. enable FDT configuration for RTxxxx family
>>
>> First thing may help you to bring if_rt up. Second one may help to work
>> in right direction, because FDT makes adding new SoC support to looks
>> like writing config (except some new devices, which will require new
>> driver for it).
>>
>> I'm glad to help, but currently limited in time I can spend.
>> Anyway, I will try to answer your questions ASAP.
>>
>> Thank you!
>>
>> [1] http://dev.mt.mk.ua/patch-20150519.diff.gz)
>>
>> WBW
>> --
>> Aleksandr Rybalko <ray at ddteam.net>
>
> Hi Aleksandr,
>
> Thanks for the patch! I’ll have a look at it and will see what I can do. Also, thanks for your offer to answer my questions, I really appreciate it.
>
> I was thinking of FDT for the Ralink/Mediatek support, but I figured it would be beneficial to see if there is interest in these platforms at all in the community or not, so that’s why I first started working on adding basic support for more SoCs before trying to move to FDT (although I agree that moving to FDT first may have been wiser :-)).
>
> I am willing to work on moving the Ralink/Mediatek family support to FDT and doing more work on supporting currently unsupported peripherals (as far as I can be of any use), but I would only do so if the changes I make would end up committed to FreeBSD - I have no interest in doing something that will go unused by anyone…
>
> So if any committer is willing to suffer going through my patches and getting them in the tree - I’ll do my best, provided I have some spare cycles to work on this. I am also willing to do the commits myself (under proper supervision, of course) if my work is considered useful and of acceptable standards.
>
> Best wishes,
> Stanislav
>
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"