[marvell yukon] 11ab:4320 not detected

[diver]

lspci |grep Ethernet 02:05.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 02:05.0 0200: 11ab:4320 (rev 13)

[diver]

Where should i place this patch in the tree and what command i should execute to incorporate your diff to test it? Thanks!

[stippi]

Put it anywhere, like your Desktop. Then open a Terminal, cd into the Haiku trunk folder (where src and headers folder are located). Then execute this:

patch -p0 -i /path/to/the/marvell_100.diff

[diver]

Thanks stippi, it worked as expected. But now i'm in trouble building an image (marvell part builds fine)

I use Ubuntu 7.10. I used this document to setup everything ​http://www.haiku-os.org/documents/dev/building_haiku_on_ubuntu_linux_step_by_step

And this is my UserBuildConfig:

HAIKU_IMAGE_NAME        = sda7 ;
HAIKU_IMAGE_DIR         = /dev ;
HAIKU_ADD_ALL_OPTIONAL_PACKAGES = 1 ;

It was 20 of march when i checked out sources and built everything to a partition. Now whey i used "svn up " in trunk folder and sudo jam -q it compiles successfully but last modification time of every object still says 20 of march and no new marvell driver appeared on a partition.

If i use $jam -q (without sudo) i get the following error for every updated object:

Error: Failed to open source path `generated/objects/haiku/x86/release/add-ons/opengl/mesa_software_renderer/Mesa Software Renderer': Bad file descriptor
Error: Command failed: Bad file descriptor
Error: Command was:
  cp :generated/objects/haiku/x86/release/add-ons/opengl/mesa_software_renderer/Mesa\ Software\ Renderer /myfs/beos/system/add-ons/opengl

I guess i will need some help here :-(

[stippi]

You are not supposed to be root when compiling. You only need to have permissions to write to the harddrive directly. Here is how I do that:

alias haiku="sudo chmod o+rw /dev/sda; sudo chmod o+rw /dev/sda7; cd /home/stippi/haiku/haiku"

Put this line into your ~/.bashrc. After entering the new command "haiku" in any Terminal, you can jam -q haiku-image from your normal account in one pass to generate the image on the partition directly. I would delete your generated/objects folder (as root) and build from scratch, since you generated files only root can change.

[diver]

Thanks stippi! I removed genereated folder and rebuild everything, i also added alias to the .bashrc. I recompiled everyting without errors jam -q:

Creating image ...
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1,86814 seconds, 56,1 MB/s
Writing boot code to "generated/haiku.image" (partition offset: 0 bytes) ...
Populating image ...
Deleting old MIME database ...
Installing MIME database ...
Unmounting ...
...updated 282 target(s)...

But my haiku partitioin is still from 20th march. Anything else i could try?

[diver]

It seems it updates generated/haiku.image but don't write it to the partition itself.

[diver]

Ok, there was something wrong with my UserBuildConfig. I recreated it and now it writes to a partition.

[diver]

Now this is strange. I mounted haiku partition using mount -t befs /dev/sda7 /mnt/haiku

cd /mnt/haiku/beos/system/add-ons/kernel/drivers/bin
ls -la|grep marvell
-rwx--x--x 1 root root 121475 2008-03-20 16:28 marvell_yukon
lrwxrwxrwx 1 root root      0 2008-03-20 16:28 marvell_yukon_sk -> ../bin/console

So it seems that marvell_yukon_sk is a link to the /bin/console app. Something wrong here, any ideas, euan?

[diver]

Going further. i execute ./configure --build-cross-tools ../buildtools/ --include-gpl-addons and jam -q and here it is:

cd /mnt/haiku/beos/system/add-ons/kernel/drivers/bin
ls -la|grep marvell
-rwx--x--x 1 root root 121475 2008-03-26 19:55 marvell_yukon
-rwx--x--x 1 root root 121475 2008-03-26 19:55 marvell_yukon_sk

But now i get kernel panic, i wrote relevant (i hope) part of back trace on a paper:

PANIC: should never be called
<kernel>: invoke_debugger_command
<kernel>: _ParseCommand_16ExpressionParserRi
<kernel>: EvaluateCommand_16ExpressionParserPcRi
<kernel>: evaluate_debugger_command
<kernel>: kernel_debugger_loop_Fv
<kernel>: kernel_debugger
<kernel>: panic
<kernel>: /boot/beos/system/add-ons/kernel/drivers/dev/marvell_yukon_sk:_Haiku_disabled_interrupts
<kernel>: /boot/beos/system/add-ons/kernel/drivers/dev/marvell_yukon_sk:_intr_wrapper
<kernel>: int:io_interrupt_handler
<kernel>: hardware_interrupt
<kernel>: _int_bottom

[euan]

hmmm that's odd. I thought I left a comment stating I had an issue with the interrupt handlers (in the glue code). But there is no comment just the diff file.

The version up there has interrupts implemented in the glue code. I've seen the same issue once. Typing continue in the kernel debugger makes the os continue running. However it indicates that something isn't quite right.

I also tried using the defines that bypass the interrupts but it doesn't work yet.

In summary. The patch is 95% there. Still needs a tiny tweak to work I think.

[euan]

updated marvell_yukon_sk/dev/sk/glue.c with interrupts implemented. Needs someone to look at...

[euan]

no it seems my migraine deceives me. the diff is the one without irq handlers. I guess the kernel message is indicating that they should be implemented. I had a stab at it but it didn't work quite right...

added another file...

[diver]

For me typing "es" in kdl don't make the os running, it just repeat panic message. Should i try your new diff?

[euan]

Yeah simply replace the glue.c with the new one (it's not a diff) and recompile (cross fingers I didn't change anything anywhere else). :)

[diver]

Going a little further again:

Now with new glue code a don't get kdl, but a completely freeze at the latest step before app_server kick in. I enabled onscreen console debugging and written down relevant parts, here it is:

marvell_yukon_sk: init hardware
marvell_yukon_sk: found Marvell Gigabit Ethernet at 10
marvell_yukon_sk: init driver
[marvell_yukon_sk] (sck) buss_alloc_resource (3, [16], 0x0, 0xffffffff, 0x1, 0x2)
[marvell_yukon_sk] (sck) buss_alloc_resource (1, [0], 0x0, 0xffffffff. 0x1, 0x6)
[marvell_yukon_sk] (sck) interrupt moderation is 100us
[marvell_yukon_sk] (sck) Marvell Yukon Lite Gigabit Ethernet rev (0x9)
[marvell_yukon_sk] (sck) chip ver 0xb
[marvell_yukon_sk] (sck) chip dev 0x09
[marvell_yukon_sk] (sck) SK_EPROM0 = 0x10
[marvell_yukon_sk] (sck) SRAM size = 0x010000
[marvell_yukon_sk] (sck) marvell_yukon_sk: /dev/net/marvell_yukon_sk/0
[marvell_yukon_sk] (sck) () Found MII: e1000phy
[marvell_yukon_sk] (sck) () Adding entry for Ethernet node
Adding entry for Ethernet 10baseT/UTP
100baseTX-FDX, adding entry for bfs:bfs_access:1360:Operation not allwoed
media change, media 0x22 media quality 1000 speed 10000
media change, media 0x909026 media quality 1000 speed 10000

At this point screen ether goes black or flicker several times and completely freeze as num lock don't react. What wondering me is random bfs traces between marvell_yukon logs. What should i try next?

[euan]

marvell_yukon working driver for (SK) type devices.

[euan]

OK the driver is now fixed. Just needed some tweaking to pipe the interrupts through the soft - interrupt interface.

marvell_100.diff has been updated.

Don't forget to add $(X86_ONLY)marvell_yukon_sk after the "marvell_yukon" entry in /build/jam/HaikuImage

Disregard the glue.c attachment it's now redundant.

[axeld]

Maybe rename that driver to syskonnect?

[euan]

agreed, sounds much better. :)

Axel, can you commit it for me? I've no keys prepared, and a tree full of broken radeon junk. Uploaded a new diff, I just did find and replace but should be ok.

[euan]

renamed driver to syskonnect

[axeld]

I can do so tomorrow.

[axeld]

Applied in hrev24723.

[diver]

This driver works for me now, i'll reopen this ticker as sysconnect driver still not in the image (i added it manually)

[axeld]

Driver added to the image in hrev24774.

[add]

​installing metal stair rails Interior stair handrail exterior baluster Glass wood stainless wrought CONTEMPORARY designs stairways aluminum modern log banister DECK outdoor price posts vinyl curved rails