Guruplug Server Plus working to some extent... [mge1 problem SOLVED]

[Rafal Jaworowski]

On 2010-10-27, at 22:59, Milan Obuch wrote:

> On Wednesday 27 October 2010 18:44:23 Rafal Jaworowski wrote:
>> On 2010-10-27, at 16:56, Milan Obuch wrote:
>>> On Tuesday 26 October 2010 23:19:59 Kristof Provost wrote:
> 
> [snip]
> 
>>>> In any case, what I wanted to see is already printed in the boot log.
>>>> Both mge interfaces are using the correct memory locatins (0xf1076000
>>>> for mge1) and the correct PHY numbers.
>>>> 
>>>> Did you statically configure the mac addresses in the DTS for this boot?
>>> 
>>> Yes. Without that, ether addres did not initialize and needs to be set
>>> manually.
>>> 
>>> However, after looking over older mails again and trying to look at it
>>> from the other side, I found the reason. I am going to write a follow-up
>>> explaining the whole issue and how succesfully solved the problem...
>>> please wait a bit, something unrelated needs to be done now...
>> 
>> Have you got your MPP settings sorted out correctly? The second GE unit
>> connections are multiplexed with other functions of the SOC and won't work
>> without proper set-up, see the hardware spec and the description of MPP
>> bindings in the DTS sys/boot/fdt/dts/bindings-mpp.txt
>> 
> 
> Exactly this was the reason, however file you mentioned was not that helpfull 
> for me... but looking at dts for OpenRD client and hardware spec for 88F6281 I 
> got the idea and after looking a bit at linux sources for guruplug server I 
> modified my dts and this also explain why frames could be received before and 
> not sent - all pins set as gpio are inputs in a way, thus reading worked, but 
> controller output was not connected to phy, so in effect tcpdump saw input and 
> frames to be sent, but tha's on chip, and they did not get out of chip.
> 
> That's it for theory, and now some summary - I am attaching patches I used for 
> Guruplug to work, collected from older mails. Patch for mvwin.h and ehci_mv.c 
> are necessary for USB to work correctly. I mentioned them in my first mail 
> dated October 20, 2010, original source is mail from Johny Mattsson dated 
> September 18, 2010. Patch for if_mge.c makes it unnecessary to specify phy 
> handle in dts and probes them automatically, originally in mail from Norikatsu 
> Shigemura dated June 20, 2010. I modified it a bit to account for changes in 
> sources in between.
> 
> For kernel config see my first mail. New dts is attached here.
> 
> One issue still remains - mge1 has no unique ether address, all-zero is set 
> upon reboot unless explicitly set in dts. This is small issue for me, need not 
> be resolved urgently.

This issue is not easily resolved in general. U-Boot would only initialize MAC address in registers of an Ethernet controller, which was used at least once. If an Ethernet controller unit is not used at the U-Boot stage its MAC address registers remain uninitialized. Now, in our case the OS can only learn about MAC address either from DT or (in case there are all 0's) fall back to whatever was set by the firmware.

The situation can be handled in a bit more robust way when FreeBSD loader(8) is used as the last stage bootloader: it is able to retrieve MAC address from U-Boot env variables and could adjust in run time appropriate DTS nodes with values read out from the env vars regardless if a given Ethernet unit was ever used by U-Boot and its MAC address regs got set. Such a feature is not implemented yet and requires some small extension to the loader(8). Note however that in order to run loader(8) you need an API-enabled U-Boot underneath (built with CONFIG_API).

> A bit more important problem is gpio - I have line
> 
> gpio0: <Marvell Integrated GPIO Controller> mem 0xf1010100-0xf101011f irq 
> 35,36,37,38,39,40,41 on simplebus0
> 
> in boot log/dmesg output, yet there is no /dev/gpio file of similar usable 
> with gpioctl. Some LEDs are connected to gpio pins, some pins are accessible 
> through u-snap connector and thus are interesting for I/O... Any hint here?

This will not work at the moment: the gpio driver for Marvell SOC does not yet have a back-end plug in for the GPIO framework, which was recently introduced, so you won't see /dev/gpio and the gpioctl(8) isn't going to work. 

Rafal