Hello,
I have a marvell 9230 discrete card (no name, the manufacturer may be “syba”).
I have two issues that maybe some experts may help here:
1°) While Marvell indicate here: http://www.marvell.com/storage/system-so…llers/hyperduo/ that by using 2 SSd and 2 HDD on boards based 9230 you can combine hyperduo and raid, I have not been able to do it: there is not such an option by selecting 4 drives and it is not possible to do it in two steps (ie creating 2 hyperduo then trying to build a raid0 with them) because a virtual drive cannot be made using other virtual drive.
I believe, it needs a bios witch have some feature activated.
2°) I have a quite new motherboard, using a recent uefi revision, that haven’t an option to activate cards’ boot roms, meaning pushing ctrl+m on boot is useless for me: in cannot enter in my 9230 bios setup unless… I make a clear cmos!!
but there is some uefi roms or drivers for 88SE9230, can I use them and how to make the setup card accessible on boot?
I use the latest drivers and bios/firmware on station-drivers.com: http://www.station-drivers.com/index.php…c=select&id=215
BIOS Version 1.0.0.1024
Firmware Version 2.3.0.1070
Boot Loader Version 2.1.0.1008
Driver Version 1.2.0.1049
Chip Revision ID A1
Vendor ID 1B4B
Sub Vendor ID 1B4B
Device ID 9230
Sub Device ID 9230
Port Count 4
Max PCIe Speed 5Gb/s
Current PCIe Speed 5Gb/s
Max PCIe Link 2X
Current PCIe Link 2X
Supported RAID Modes RAID0, RAID1, RAID10, HyperDuo (Capacity), HyperDuo (Safe)
Supported Stripe Size 32K 64K
Maximum PD per Adapter 7
Supported VD Cache None
Maximum VD per Adapter 4
Maximum PD per VD 4
Maximum Port Multiplier 1
I wound up in the same boat as a lot of other folks for a while after I incorrectly flashed my 9215 without backing up the original first. In my case, I was very lucky in that I had a different part that also used the same chipset.
The part I screwed up on is a Linkreal LRST8615-4IT with a Marvell 88se9215 chipset on board. This is a mini pcie card that has a SAS connector on it.
After a week and a half of scouring the internet for a solution, I discovered that the pcie card that this part was replacing in my build had the exact same Marvell chipset on it. This is the Syba SI-PEX40064.
So I pulled out my chip programmer (a cheap Genius G540), and tried to read the bios chip on the Syba. No joy; it wasn’t able to pull anything from the chip. So then I took my solder to it and removed it from the card.
Attached is the image I read off that chip. I was able to flash this on my LRST8615-4IT and was able to get the thing to at least show disks once the OS was loaded. I don’t need boot support, so it is fine for me.
Of note in the image is that there is very little data in it. Only the top few lines have anything, and they appear to be the bootloader code.
So for anyone else out there who accidentally flashed their 9215’s incorrectly, this file may be a fix for you. Just rename the .txt to .bin
SI-PEX40064.txt (512 KB)
Hi Fernando
i know this might not be the correct section to ask for some help, but hopefully you can.
Background to what i have
1. Qnap TS-EC1279U-RP
2. Backplane with 5x 88SE9125 Controllers
3. Connected with what i think is a single PCIE
4. The firmware/rom is not included in the Motherboard Bios, so seperate flash as far as im aware.
5. i was stupid and did not do a backup of the controllers before i flashed them…
Now the problem
All was working fine, it is my unraid machine
I was on the task to try get IMMOU working on the machine, and there was an issue with IMMOU and the Marvell chipset in unraid.
So i basically flashed the 9125s with what i thought would be a fix ( i didnt do enough reading before hand )
Since then, i have been scouring the forums trying to find a image to use that will work with my 9125 controllers.
Now from what i can tell, the good news is the controller is still picked up by mvf_mag
And is picked up in windows/linux.
But no matter what combination i use, i cannot get the backplane to work with any drives plugged in.
I have tried myself to modify dev ids on the rom, and autoloader, but i literally cannot find any image files created for a 9125 marvell controller.
So basically, am i out of luck, unless someone else has a backup image from a 9125 controller?
@jayrodksmith :
Welcome to the Win-RAID Forum!
Since your problem seems to be Firmware and not driver related, I have moved your help request into this thread and hope, that you will get support by someone, who lnows more about this specific topic than me.
The support will be relieved, if you give some additional information regarding the HardwareIDs of your Marvell Controller and the Firmware, which had been flashed by you.
Good luck!
Dieter (alias Fernando)
@Fernando
Thanks, i will grab the image and details tomorrow so hopefully someone smart can help me out.
I haven’t seen these posted anywhere so I’ll post them here. These are off a dump I took from a 9120 card I recently purchased.
All I have is Autoload and BIOS. This is a very simple card.
Extracted with Lordkag’s script.
BIOS 9120 1.1.0.1002.bin.zip (19.2 KB)
Autoload 9120-9120 0.0.3.2050.bin.zip (381 Bytes)
25L4006E.zip (20.3 KB)
Resurrecting an old discussion in this topic for a bit to share my expereince with the Marvell 9128 on my Gigabyte GA-X58A-UD5 rev.1 motherboard. Maybe it will help others who plan to mod motherboards from this series. The information in this topic was invaluable for me so thank you all who tested before me!
This motherboard uses a 512Kb chip to store the Marvell firmware, loader, ROM etc. independent of the BIOS as lordkag explored back in 2014 with the UD3R version of the board.
The latest BIOS for this motherboard contains 2 files seemingly related to this controller:
- GRAID.BIN - 25Kb - this LOOKS LIKE a Marvell ROM as the beginning is very similar to other Marvell ROMs, verison number is 1.0.0.1003.
- M9123FW.BIN - 512Kb - this contains the autoload, firmware, hw_config etc. and another Marvell ROM, this time version number 1.0.0.1029. This is a straight dump of the contents of the 512Kb chip that you can update with the Marvell Firmware update tools and images.
In the BIOS you can set the SATA3 controller firmware mode to FORCE or ONCHIP. When you set it to FORCE, during boot the contents of the M9123FW.BIN in the BIOS gets written to the 512Kb chip byte-for-byte.
If you look at earlier versions of the BIOS you can notice that when the Gigabyte BIOS release notes mention “Improved SATA3 RAID performance” the GRAID.BIN is still 1.0.0.1003 but the ROM version in the M9123FW.BIN is higher.
So why would Gigabyte update the Marvell ROM in their BIOS only in the firmware dump and why leave GRAID.BIN alone? Another observation is that the Marvell ROM prompt does not show up during boot at all, there is no option to press Ctrl+M anywhere during the boot process.
So here is what I think:
1. Gigabyte wanted to provide easy Marvell FW updates to their customers without DOS booting Marvell firmware utilities, but they couldn’t include the whole Marvell toolset in the BIOS. So instead they came up with this: they update a motherboard with the Marvell tools, DUMP the contents of the chip, and include that in the BIOS with a simple program that copies byte for byte the 512Kb image to the chip.
Then they give the user the option in the BIOS to FORCE update the chip contents.
2. The original Marvell ROM slowed down the boot process, expecially with an Intel RAID ROM and a JMicron RAID ROM also on the system, so they moved the Marvell RAID configuration into the BIOS. This is where GRAID.BIN comes in. If you change/replace GRAID.BIN in the BIOS with a proper Marvell ROM, you can’t enter the Marvell RAID configuration from the BIOS anymore. The firmware and everything works, but you can’t configure RAID from the BIOS. Nothing happens when you select that option.
If you leave GRAID.BIN alone and only update the firmware etc. on the 512Kb chip, the RAID configuration from the BIOS works.
I believe Gigabyte created a hacked dummy Marvell ROM that enabled the user to hop into the Marvell RAID configuration from the BIOS without going through the boot process and pressing Ctrl+M. The actual Marvell RAID ROM that is used is always on the 512Kb chip. You can get to the Marvell RAID configuration menu from the BIOS and it will say the ROM version that is on the 512Kb chip. This mysterious 1.0.0.1003 version ROM is not actually used by the 9128 controller.
So this means you can provide the entire Marvell firmware update straight in the BIOS for these boards, you just have to recreate M9123FW.BIN. And this is what I did.
I took the latest parts available in this topic, flashed the Marvell firmware image on my computer, dumped the 512Kb chip contents, examined it and recreated it from the parts available with the right offsets, padding etc. in a hex editor (I did this to make sure no errors slip in during the dump. The dump tool inserted some weird characters sometimes into the FF padding parts.) I then tested the franken-spliced image, compared it to the dump until it was identical.
Here is a link for the M9123FW.BIN with the following parts:
- Autoload 2.0.0.061D
- ROM with deviceID 9123 v1.0.0.1038
- Firmware v2.3.0.1007
The parts were taken from the attached image in this post. The final firmware would be what lordkag describes here as Test3 with the newest available parts.
I tested this on my GA-X58A-UD5 rev.1 and the Marvell controller works, the versions are correct in the RAID BIOS and in the OS, the FORCE update function works without problems and the RAID configuration is available from the BIOS.
This is a dump for a four port Marvell 9215 controller. The model of the card is PCE4SAT-M02
2
3
4
5
6
7
8
9
10
11
12
13
14
1. Autoload.bin was extracted. Offset = 0x00 and Size = 0x58
2. HW_Config.txt was extracted. Offset = 0x1000 and Size = 0x5C
3. Desc.txt was extracted. Offset = 0x2000 and Size = 0x77
4. No SPIList.bin is found! Nothing to extract.
5. No Loader is found! Nothing to extract.
6. Bios.bin was extracted. Offset = 0x10000 and Size = 0x7C00
X. No Firmware is found! Nothing to extract.
7. No Program0 is found! Nothing to extract.
8. No Program1 is found! Nothing to extract.
9. No BIOS_UI is found! Nothing to extract.
10. No DSRAM_DATA is found! Nothing to extract.
11. No END_info is found! Nothing to extract.
2
3
4
Autoload 92xx 2.0.0.2005_RevA1.bin
BIOS 9215 1.0.0.1028.bin
9215 dump.zip (19.8 KB)
The firmware above is;
Although it does not seem to be complete.
Zitat von chinobino im Beitrag #209
The firmware above is;
Although it does not seem to be complete.
I don’t know what to say… This is a straight dump off the SPI chip… The chip has no RAID functionality, so perhaps this is sufficient for such a card. Either way, the card’s intended purpose was for optical drive testing with Marvell, so I’ll see how that goes.
Hey everyone,
there might be some newer versions for the Marvell 88SE9230. This controller is used on a sata raid extension card for some Lenovo servers (e.g. ThinkSystem SR665).
The card has the name “ThinkSystem M.2 SATA 2-Bay RAID Adapter” or “M.2 SATA 2-Bay RAID Enablement Kit” (SKU: 4Y37A09739).
The description says that it uses the 88SE9230 even though it is advertised with only 2 ports.
There are two firmware downloads for them:
excerpt from changelog:
- Version: 2.3.16.1005 (BBFV_5)
- Date Release: 05/11/2018
- Author: Marvell Enterprise Storage Software Team
- Modules:
(SYMBOL * means has new version)
Autoload : 200019
Loader : 2.1.0.1009
Firmware : 2.3.16.1089 ()
BIOS : 1.0.0.1031 ()
UEFI driver : 1.1.10.1037 (MS)
HII : 0.0.16.1002 (* Non-MS )
ConsoleDriver : 1.0.0.1027
MSU : 4.1.10.2041 (Window)
4.1.10.2040 (Linux)
CLI : 4.1.10.36 (Window)
4.1.10.36 (Linux)
uEFI_CLI : 1.0.10.13
APISDK : 2.3.10.1069_2
and
- Version: 2.3.20.1011
- Modules:
(SYMBOL * means has new version)
Autoload : 200019
Loader : 2.1.0.1009
Firmware : 2.3.20.1211
BIOS : 1.0.0.1031
UEFI driver : 1.1.10.1044 (MS)
HII : 0.0.20.1016 (*MS)
Currently, the newest version available here is BIOS/UEFI 1.0.0.1029 and FW 2.3.0.1078…at least that’s the newest one in one of the archives I downloaded from here.
Unfortunately, these new images don’t seem to be in a format that we’re used to. The 2.3.16.1005 image file is > 900 kbyte. The PCIe cards with that controller that I’ve seen only have an SPI flash with ~500 kbyte space.
The 2.3.20.1011 image is split in two files. I don’t know why or what’s the difference between them. There might be some Lenovo specific parts in them.
However, with the tooling that we already have at our hands, it should be possible to extract the newer parts and build an updated image with the image builder.
…I’ve not tried any of that but I still wanted to share the discovery
…maybe we can also request an update with these versions from the PCIe card brands that sell these (Syba, Startech, Highpoint, Ableconn, etc.)
Good work, keep it coming…
A quick analise, the BIN files are combined FW/EFI/Loader etc… if they could be used for individual updates they must be dissected.
Not going to waste time with it for now, but thank you for your contributions.
lol, there is even newer stuff…released May 15th 2023
The Dell BOSS-S1 and BOSS-S2 for many EMC Poweredge Servers are based on these Marvell Chips…can’t tell if it’s 91xx or 92xx as of now.
Anyway, heres the link for BOSS-S2 2.5.13.4009
PACKAGE VERSION[0xFFFFFFFF]: 2.3.13.4009
ROM VERSION[0x00000000]: 2.5.13.4009
AUTOLOAD VERSION[0x00000000]: 2.0.0.0019
LOADER VERSION[0x0000C000]: 2.1.0.1009
BIOS VERSION[0x00020000]: 1.0.13.1007
UEFI VERSION[0x00020000]: 1.1.13.1010
FIRMWARE VERSION[0x00030000]: 2.3.13.1409
And BOSS-S1 2.6.13.3025 from 29 May 2023
PACKAGE VERSION[0xFFFFFFFF]: 2.3.13.3026
ROM VERSION[0x00000000]: 2.6.13.3025
AUTOLOAD VERSION[0x00000000]: 2.0.0.0019
LOADER VERSION[0x0000C000]: 2.1.0.1009
BIOS VERSION[0x00020000]: 1.0.13.1004
UEFI VERSION[0x00020000]: 1.1.13.1010
FIRMWARE VERSION[0x00030000]: 2.5.13.1215
The numbering doesn’t make sense however…
There might be more for other servers ^^
I might get into dissecting these in the future…it’s so stupid you have to jump through so many hoops to get these stupid updates…
All 9230 (4B 1B 30 92)
Thanks to the previous work of lordkag, I dissected the Dell BOSS S1 and S2 images. See the attachment. I further dissected some parts, which you can find in the additional files directory. The goal was to rebuild the original dell images.
Some warnings however:
I might have made some errors when dissecting them. So don’t just flash them, lol. Validity can only be established if I can rebuilt the exact same image as the original (not yet possible). More on that further down.
Key differences to the usual images:
- The image is 1024Kb in size
- The exact same internal FW is present at 0x40000 and 0x90000
- BIOS OROM and UEFI OROM are combined into a single OROM (bios.bin)
- UEFI OROM contains 3 sections (any guesses?)
- autoload.bin has some new stuff but without documentation I don’t know what they do
- The versioning of the internal FW is 000000001. Makes no sense. Actual version is probably the one in
desc.txt
Issues with rebuilding the original BOSS images:
There is a way to make the internal FW appear two times in the image via config.txt. I have not found out how to do it yet, since there is no documentation. Running strings on the image builder .exe hints that there can be a IMAGE_TYPE key in the IMAGE_HDR section with the values SINGLE, DUAL_SAME and DUAL_DIFF. Don’t know how to apply that yet.
The files for building the images (al_tran_win32.exe, ImageHeaderGenerator.exe, imgCreate.exe, ReadMe.txt, RUN-Generating_RAWImage.bat) were taken from Marvell_9230_A0+A1_Firmware+Tools_Update3.zip , downloaded somewhere here.
Next, I’ll try to create a flash image for my Delock 89395. If anyone else joins this, make sure to first make a backup with the go -r stuff and maybe backup the configuration with mdu_mag restore_cfg -g 0. I don’t know if this configuration even resides in the flash image.
A CH341A programmer might also be needed.
The challange here is the size…I need to somehow cram that stuff into 512Kb
Also: If we believe the imgCreate.exe, the versioning is: [major.minor.oem.beta.alpha]
Dell_BOSS_S1_S2_dissected.zip (5.4 MB)
Next, I’ll try to create a flash image for my Delock 89395.
Yeah…just did that and failed. PC doesn’t boot anymore with the card inserted. I had to move around some sections in the flash image to make it smaller, which apparently causes the initialization sequence to fail (or the image contents themselves). Don’t know what exactly the problem is. Could be anything. Need more documentation…or a lot of time for debugging, which I don’t have right now.
Again, if anyone gets into this. Make a backup and get a SPI programmer…or a hot air station and a bigger flash chip…
My current CH341A can’t detect the chip for some reason…
I’ll probably come back to this at some point in the future (6+ months)…