Date: Sat, 30 Oct 2010 15:02:43 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Milan Obuch <freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... [mge1 problem SOLVED] Message-ID: <DEF142CA-E6D8-4521-8DB4-D9AB604E919C@semihalf.com> In-Reply-To: <201010272259.36319.freebsd-arm@dino.sk> References: <201010202309.40148.freebsd-arm@dino.sk> <201010271656.53245.freebsd-arm@dino.sk> <7C9980A5-1812-4162-82E0-2374EACFA24A@semihalf.com> <201010272259.36319.freebsd-arm@dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 > [snip] >=20 >>>> 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. >>>>=20 >>>> Did you statically configure the mac addresses in the DTS for this = boot? >>>=20 >>> Yes. Without that, ether addres did not initialize and needs to be = set >>> manually. >>>=20 >>> 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... >>=20 >> 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 >>=20 >=20 > Exactly this was the reason, however file you mentioned was not that = helpfull=20 > for me... but looking at dts for OpenRD client and hardware spec for = 88F6281 I=20 > got the idea and after looking a bit at linux sources for guruplug = server I=20 > modified my dts and this also explain why frames could be received = before and=20 > not sent - all pins set as gpio are inputs in a way, thus reading = worked, but=20 > controller output was not connected to phy, so in effect tcpdump saw = input and=20 > frames to be sent, but tha's on chip, and they did not get out of = chip. >=20 > That's it for theory, and now some summary - I am attaching patches I = used for=20 > Guruplug to work, collected from older mails. Patch for mvwin.h and = ehci_mv.c=20 > are necessary for USB to work correctly. I mentioned them in my first = mail=20 > dated October 20, 2010, original source is mail from Johny Mattsson = dated=20 > September 18, 2010. Patch for if_mge.c makes it unnecessary to specify = phy=20 > handle in dts and probes them automatically, originally in mail from = Norikatsu=20 > Shigemura dated June 20, 2010. I modified it a bit to account for = changes in=20 > sources in between. >=20 > For kernel config see my first mail. New dts is attached here. >=20 > One issue still remains - mge1 has no unique ether address, all-zero = is set=20 > upon reboot unless explicitly set in dts. This is small issue for me, = need not=20 > 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 >=20 > gpio0: <Marvell Integrated GPIO Controller> mem 0xf1010100-0xf101011f = irq=20 > 35,36,37,38,39,40,41 on simplebus0 >=20 > in boot log/dmesg output, yet there is no /dev/gpio file of similar = usable=20 > with gpioctl. Some LEDs are connected to gpio pins, some pins are = accessible=20 > 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.=20 Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DEF142CA-E6D8-4521-8DB4-D9AB604E919C>