headers
Łukasz Siemiradzki | 5 Mar 2011 17:13
X-Face
Picon
Gravatar

Can't access SD card under sheevaplug

Hello,
 I'm not able to operate on SD card attached to Sheevaplug. I'm sure that card 
isn't broken. It contains single fat partition. Please see below:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

NetBSD 5.99.47 (ZONIAK) #1: Sun Feb 27 14:15:46 CET 2011
        root <at> volkov.localdomain.:/netbsd/obj/sys/arch/evbarm/compile/ZONIAK
total memory = 512 MB
avail memory = 497 MB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0: Sheeva 88SV131 rev 1 (ARM9E-S core)
cpu0: DC enabled IC enabled WB enabled EABT branch prediction enabled
cpu0: 16KB/32B 4-way Instruction cache
cpu0: 16KB/32B 4-way write-back-locking-C Data cache
mvsoc0 at mainbus0: Marvell 88F6281 Rev. A0  Kirkwood
mvsoc0: CPU Clock 1200.000 MHz  SysClock 400.000 MHz  TClock 200.000 MHz
mvsoctmr0 at mvsoc0 unit 0 offset 0x20300-0x203ff: Marvell SoC Timer
mvsocgpp at mvsoc0 unit 0 not configured
com0 at mvsoc0 unit 0 offset 0x12000-0x1201f irq 33: ns16550a, working fifo
com0: console
com1 at mvsoc0 unit 1 offset 0x12100-0x1211f irq 34: ns16550a, working fifo
ehci0 at mvsoc0 unit 0 offset 0x50000-0x51fff irq 19: Marvell USB 2.0 Interface
ehci0: EHCI version 1.0
usb0 at ehci0: USB revision 2.0
gttwsi0 at mvsoc0 unit 0 offset 0x11000-0x11fff irq 29: Marvell TWSI controller
iic0 at gttwsi0: I2C bus
mvcesa at mvsoc0 unit 0 not configured
mvgbec0 at mvsoc0 unit 0 offset 0x70000-0x73fff: Marvell Gigabit Ethernet
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Mills | 5 Mar 2011 19:14

Re: [guruplug] mvgbe1 no PHY found


>If someone have idea/patch for the 'mvgbe1: no PHY found!' ...
This is not really clear from the documentation but it would appear that the
two PHYs can only be accessed from the registers of controller0 (mvgbec0)
hence why both PHYs are being detected on controller0.

I have made the assumption that PHY0 => controller0 (mvgbec0), PHY1 =>
controller1(mvgbec1) and developed a patch accordingly. 

Also the irq is 15 for controller1 not 14.

Index: if_mvgbe.c
===================================================================
RCS file: /cvsroot/src/sys/dev/marvell/if_mvgbe.c,v
retrieving revision 1.5
diff -u -r1.5 if_mvgbe.c
--- if_mvgbe.c	1 Feb 2011 23:40:12 -0000	1.5
+++ if_mvgbe.c	5 Mar 2011 18:07:03 -0000
 <at>  <at>  -184,6 +184,7  <at>  <at> 

 struct mvgbec_softc {
 	device_t sc_dev;
+	int sc_unit;

 	bus_space_tag_t sc_iot;
 	bus_space_handle_t sc_ioh;
 <at>  <at>  -277,6 +278,7  <at>  <at> 
 CFATTACH_DECL_NEW(mvgbe, sizeof(struct mvgbe_softc),
     mvgbe_match, mvgbe_attach, NULL, NULL);
(Continue reading)

Permalink | Reply | 5 comments |
headers
rjs | 6 Mar 2011 22:43
Picon
Picon

Re: [guruplug] mvgbe1 no PHY found


Dave Mills wrote:
>>If someone have idea/patch for the 'mvgbe1: no PHY found!' ...
>This is not really clear from the documentation but it would appear that the
>two PHYs can only be accessed from the registers of controller0 (mvgbec0)
>hence why both PHYs are being detected on controller0.

No, the PHYs can be accessed through the SMI register for each port.

The problem is that the wrong bus space handle is being used in the
mvgbe_miibus_* functions, they should use the one for the port not
the controller, the offset for the SMI register needs changing too.

>I have made the assumption that PHY0 => controller0 (mvgbec0), PHY1 =>
>controller1(mvgbec1) and developed a patch accordingly. 

There is only one controller in the CPU used in the Sheevaplug and
Guruplug, it has two ports.

Robert Swindells
Permalink | Reply | 4 comments |
headers
Dave Mills | 7 Mar 2011 00:33

Re: [guruplug] mvgbe1 no PHY found


>No, the PHYs can be accessed through the SMI register for each port.

>The problem is that the wrong bus space handle is being used in the
>mvgbe_miibus_* functions, they should use the one for the port not
>the controller, the offset for the SMI register needs changing too.

PHY Address Register Port0: 0x72004, Port1: 0x76004
(P554 88F6180, 88F6190,88F6192, and 88F6281 Integrated Controller Functional
Specifications)

I checked the addresses read by the mvgbe_miibus_* functions (bus space
handle + MVGBE_SMI) and they match up to the offsets quoted above
(+0xf1000000 for register base address)
SMI register is a controller register not a port register.
(if we were using the port bus space handle we would be reading offsets of
0x72400+ and 0x76400+)

>There is only one controller in the CPU used in the Sheevaplug and
>Guruplug, it has two ports.

"The 88F6192 and 88F6281 implement two GbE controllers"
(P113 88F6180, 88F6190,88F6192, and 88F6281 Integrated Controller Functional
Specifications)

Dave Mils
--

-- 
View this message in context: http://old.nabble.com/-guruplug--mvgbe1-no-PHY-found-tp30876058p31083734.html
Sent from the port-arm mailing list archive at Nabble.com.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Mills | 7 Mar 2011 01:34

Re: [guruplug] mvgbe1 no PHY found


There is a slight bug (typo) in the cf_unit abuse update to cvs for
if_mvgbe.c

Incidentally what is cf_unit abuse? 

The update works fine on the guruplug with the patch below applied however
if there is ever a device released with more than two PHYs it wont work.

Dave Mills

Index: ./sys/dev/marvell/if_mvgbe.c
===================================================================
RCS file: /cvsroot/src/sys/dev/marvell/if_mvgbe.c,v
retrieving revision 1.7
diff -u -r1.7 if_mvgbe.c
--- ./sys/dev/marvell/if_mvgbe.c        6 Mar 2011 17:00:16 -0000       1.7
+++ ./sys/dev/marvell/if_mvgbe.c        7 Mar 2011 00:26:01 -0000
 <at>  <at>  -619,7 +619,6  <at>  <at> 
 mvgbe_attach(device_t parent, device_t self, void *aux)
 {
        struct mvgbe_softc *sc = device_private(self);
-       struct mvgbec_softc *csc = device_private(parent);
        struct marvell_attach_args *mva = aux;
        struct mvgbe_txmap_entry *entry;
        struct ifnet *ifp;
 <at>  <at>  -767,7 +766,7  <at>  <at> 
        ifmedia_init(&sc->sc_mii.mii_media, 0,
            mvgbe_mediachange, mvgbe_mediastatus);
        mii_attach(self, &sc->sc_mii, 0xffffffff,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan A. Kollasch | 7 Mar 2011 02:24
Gravatar

Re: [guruplug] mvgbe1 no PHY found

On Sun, Mar 06, 2011 at 04:34:35PM -0800, Dave Mills wrote:
> 
> There is a slight bug (typo) in the cf_unit abuse update to cvs for
> if_mvgbe.c
> 
> Incidentally what is cf_unit abuse? 
> 
> The update works fine on the guruplug with the patch below applied however
> if there is ever a device released with more than two PHYs it wont work.
> 

Can we just use the 'phy' locator we already have?

For example in the kernel config(5):
(revert to if_mvgbe.c 1.5 for this)

mvgbe0 at mvgbec0 port 0 
mvgbe1 at mvgbec0 port 1
makphy0 at mvgbe0 phy 0
makphy1 at mvgbe1 phy 1

Or even, as found on my Orion-based NAS:
makphy0 at mvgbe0 phy 8

	Jonathan Kollasch
Permalink | Reply | 1 comment |
headers
Dave Mills | 7 Mar 2011 13:26

Re: [guruplug] mvgbe1 no PHY found


>Can we just use the 'phy' locator we already have?

>For example in the kernel config(5):
>(revert to if_mvgbe.c 1.5 for this)

>mvgbe0 at mvgbec0 port 0 
>mvgbe1 at mvgbec0 port 1
mvgbe1 at mvgbec1 port 0 (2 controllers one port on each)
>makphy0 at mvgbe0 phy 0
>makphy1 at mvgbe1 phy 1

I dont think so.... currently mvgbe_attach uses a helper routine from mii.c
to identify the PHYs.
I've looked at a few other network drivers and they seem to use this helper
routine rather than autoconf(9) too.  (I must admit I'm still getting my
head around the autoconf process)

>Or even, as found on my Orion-based NAS:
>makphy0 at mvgbe0 phy 8

A PHY located at address 8 presents more of an issue..the patches submitted
to cvs would currently break support for your device as i had assumed
mvgbec0=>phy0, mvgbec1=>phy1

a solution could be mvgbec0 => 1st phy found, mvgbec1=> 2nd phy found .. the
helper function supports this if we specify a phy offset rather than a phy
address. (Though this still doesnt address the issue of >2 PHYs)

as in the patch below:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Mills | 10 Mar 2011 17:05

Re: Some issues on Sheevaplug


>Using my Sheevaplug and NetBSD, I encountered three issues :

>- When I use the serial console for a long time, my Sheevaplug hangs up
(nothing to report with OpenSSH).

The problem is with the interrupt system.
On the kirkwood series of chips there are two interrupt cause registers - a
low one and a high one.
kirkwood.c splits the high and low register up into two pics with the high
register pic being chained off the low register pic on BIT0 (MainHighSum)
this is incorrect as masking off this bit does not stop interrupts on the
high register from firing.  The correct way of doing this is to have one pic
for both registers.

The reason the serial console hangs is that the processor is trying to
execute atomic functions (atomic_or_32) in pic_mark_pending_sources which
restart when returning from an interrupt (LOCK_CAS) and since the high
register interrupt is not being masked off the atomic functions never
complete as they are constantly being interrupted with interrupts from the
UART.

Most of the time this isnt an issue as the current design establishes the
"high register interrupt" as IPL_HIGH and is allowed to run the high
register interrupt handler and block the relevant high interrupt bit -
however when running other IPL_HIGH code it just masks off BIT0
(MainHighSum) in the low register and marks it as pending and doesnt
immediately run the high register interrupt handler.

The code uses a single pic for low and high registers:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Łukasz Siemiradzki | 12 Mar 2011 23:08
X-Face
Picon
Gravatar

undefined reference to `_splraise'

Hello,
 I just trying to build current sheevaplug kernel and userland. Compilation 
stops with following error:

head /netbsd/logs/build_current.log 
===> build.sh command:    ./build.sh -j 4 -D /netbsd/destdir -O /netbsd/obj -T 
/netbsd/tools -R /netbsd/release -m evbarm -r tools kernel=SHEEVAPLUG build
===> build.sh started:    Sat Mar 12 21:20:09 CET 2011
===> NetBSD version:      5.99.48
===> MACHINE:             evbarm
===> MACHINE_ARCH:        arm
===> Build platform:      FreeBSD 8.2-RC2 amd64
===> HOST_SH:             /bin/sh
===> Bootstrapping nbmake
checking for sh... /bin/sh
checking for gcc... cc

...

--- vers.o ---
#    create  vers.c
/bin/sh /netbsd/src/sys/conf/newvers.sh 
#   compile  SHEEVAPLUG/vers.o
/netbsd/tools/bin/arm--netbsdelf-gcc  -ffreestanding -fno-zero-initialized-in-
bss -g -O2 -O2 -fno-strict-aliasing   -Werror -Wall -Wno-main -Wno-format-
zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch 
-Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-sign-compare -
Wno-pointer-sign -Wno-attributes  -Werror -march=armv5te  -I.  -
I/netbsd/src/sys/../common/include -I/netbsd/src/sys/arch  -I/netbsd/src/sys -
nostdinc -D__HAVE_PCI_CONF_HOOK -DKERNEL_BASE_EXT="0xc0000000" -
(Continue reading)

Permalink | Reply | 2 comments |
headers
NONAKA Kimihiro | 12 Mar 2011 23:39
Picon
Gravatar

Re: undefined reference to `_splraise'

Please update sys/arch/arm/marvell/files.marvell rev.1.4.

2011/3/13 Łukasz Siemiradzki <lukasz.siemiradzki <at> gmail.com>:
> Hello,
>  I just trying to build current sheevaplug kernel and userland. Compilation
> stops with following error:
>
> head /netbsd/logs/build_current.log
> ===> build.sh command:    ./build.sh -j 4 -D /netbsd/destdir -O /netbsd/obj -T
> /netbsd/tools -R /netbsd/release -m evbarm -r tools kernel=SHEEVAPLUG build
> ===> build.sh started:    Sat Mar 12 21:20:09 CET 2011
> ===> NetBSD version:      5.99.48
> ===> MACHINE:             evbarm
> ===> MACHINE_ARCH:        arm
> ===> Build platform:      FreeBSD 8.2-RC2 amd64
> ===> HOST_SH:             /bin/sh
> ===> Bootstrapping nbmake
> checking for sh... /bin/sh
> checking for gcc... cc
>
> ...
>
> --- vers.o ---
> #    create  vers.c
> /bin/sh /netbsd/src/sys/conf/newvers.sh
> #   compile  SHEEVAPLUG/vers.o
> /netbsd/tools/bin/arm--netbsdelf-gcc  -ffreestanding -fno-zero-initialized-in-
> bss -g -O2 -O2 -fno-strict-aliasing   -Werror -Wall -Wno-main -Wno-format-
> zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch
> -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-sign-compare -
(Continue reading)

Permalink | Reply | 1 comment |

Gmane