BX100: there is a Linux tool to flash ROM images through any SATA adapter

[Elmar Stellnberger]

Hi everyone,

  Lately I have updated the firmware of my BX100 SSD drive with the boot 
CD as provided by http://www.crucial.com/support/ssd. As it turned out 
the boot CD is powered by Linux and the busybox the firmware image being 
provided under /opt/firmware/MU02/1.bin in /boot/core.gz which is a 
gzipped cpio file.
  Would anyone care to analyse this media? I would love to see HDD/SSD 
firmware flashing being supported by flashrom through some more SATA 
controllers.

Elmar

P.S.: if my hint should not have been particularely helpful I would like 
to know about that as well ...

[Jonathan A. Kollasch]

On Tue, Jan 12, 2016 at 06:47:43PM +0100, Elmar Stellnberger wrote:
> Hi everyone,
>
> Lately I have updated the firmware of my BX100 SSD drive with the
> boot CD as provided by http://www.crucial.com/support/ssd. As it
> turned out the boot CD is powered by Linux and the busybox the
> firmware image being provided under /opt/firmware/MU02/1.bin in
> /boot/core.gz which is a gzipped cpio file.
>  Would anyone care to analyse this media? I would love to see
> HDD/SSD firmware flashing being supported by flashrom through some
> more SATA controllers.
>
> Elmar
>
> P.S.: if my hint should not have been particularely helpful I would
> like to know about that as well ...

Flashrom expects to be able to access flash chips directly.
ATA's DOWNLOAD MICROCODE commands are almost certainly completely
unsuitable for the architecture of flashrom.  (Assuming they aren't
using some vendor-specific ATA command to do firmware updates.)

	Jonathan Kollasch

[Luc Verhaegen]

On Tue, Jan 12, 2016 at 06:47:43PM +0100, Elmar Stellnberger wrote:
> Hi everyone,
>
> Lately I have updated the firmware of my BX100 SSD drive with the boot CD
> as provided by http://www.crucial.com/support/ssd. As it turned out the boot
> CD is powered by Linux and the busybox the firmware image being provided
> under /opt/firmware/MU02/1.bin in /boot/core.gz which is a gzipped cpio
> file.
>  Would anyone care to analyse this media? I would love to see HDD/SSD
> firmware flashing being supported by flashrom through some more SATA
> controllers.
>
> Elmar
>
> P.S.: if my hint should not have been particularely helpful I would like to
> know about that as well ...

I recently had a quick look at something related, and noticed that there 
is a well-defined ATAPI call to flash the firmware. It can be found in 
the publically available atapi specs.

Luc Verhaegen.

[Luc Verhaegen]

On Tue, Jan 12, 2016 at 06:47:43PM +0100, Elmar Stellnberger wrote:
> Hi everyone,
>
> Lately I have updated the firmware of my BX100 SSD drive with the boot CD
> as provided by http://www.crucial.com/support/ssd. As it turned out the boot
> CD is powered by Linux and the busybox the firmware image being provided
> under /opt/firmware/MU02/1.bin in /boot/core.gz which is a gzipped cpio
> file.
>  Would anyone care to analyse this media? I would love to see HDD/SSD
> firmware flashing being supported by flashrom through some more SATA
> controllers.
>
> Elmar
>
> P.S.: if my hint should not have been particularely helpful I would like to
> know about that as well ...

/sbin/msecli is where the magic is, and strings shows that that is 
filled with a load of atapi/smart stuff.

Luc Verhaegen.

[Stefan Tauner]

On Tue, 12 Jan 2016 10:15:00 -0600
"Jonathan A. Kollasch" <[e-mail]> wrote:
> On Tue, Jan 12, 2016 at 06:47:43PM +0100, Elmar Stellnberger wrote:
> > Hi everyone,
> >
> > Lately I have updated the firmware of my BX100 SSD drive with the
> > boot CD as provided by http://www.crucial.com/support/ssd. As it
> > turned out the boot CD is powered by Linux and the busybox the
> > firmware image being provided under /opt/firmware/MU02/1.bin in
> > /boot/core.gz which is a gzipped cpio file.
> >  Would anyone care to analyse this media? I would love to see
> > HDD/SSD firmware flashing being supported by flashrom through some
> > more SATA controllers.
> >
> > Elmar
> >
> > P.S.: if my hint should not have been particularely helpful I would
> > like to know about that as well ...
>
> Flashrom expects to be able to access flash chips directly.

No, it doesn't. opaque.c, nicintel_eeprom.c.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

[Stefan Tauner]

On Tue, 12 Jan 2016 18:47:43 +0100
Elmar Stellnberger <[e-mail]> wrote:
> I would love to see HDD/SSD 
> firmware flashing being supported by flashrom through some more SATA 
> controllers.

Unless it supports at least some kind of addressing I don't deem it
within the scope of flashrom. Just reading a complete file and piping
it into an API (which library do they use BTW?) is nothing exciting that
requires the whole infrastructure of flashrom.
By addressing I mean e.g. a way to write only part of the underlying
flash memory.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

[Elmar Stellnberger]

I have just tested this utility:

./msecli -U -i ../opt/frimware/MU02 -m BX100
./msecli -L

did work as expected (flashing the firmware and listing the firmware 
status of the device) besides the many other useful options it offers 
apart from flashing the firmware (debug-log, secure-erase, ... )

./msecli -D -n /dev/sde ... did print a success message for a clean new 
drive from factory but no more information

while (the following command should prepare the drive for removal)
./msecli -Z -n /dev/sde
says:
This command is not supported for the drive.
however it is recognized as BX100 since I get another error message with 
non crucial drives.

nice.


Am 2016-01-12 um 18:02 schrieb Luc Verhaegen:
> /sbin/msecli is where the magic is, and strings shows that that is
> filled with a load of atapi/smart stuff.
>
> Luc Verhaegen.

[Carl-Daniel Hailfinger]

On 12.01.2016 20:53, Stefan Tauner wrote:
> On 12.01.2016 17:15, Jonathan A. Kollasch wrote:
> > Flashrom expects to be able to access flash chips directly. 
> > No, it doesn't. opaque.c, nicintel_eeprom.c.

Well, flashrom expects to access flash chips somewhat directly.

If by "directly" you mean the ability to send commands to the flash
chip, see Stefan's response.
If by "directly" you mean the ability to access/modify the flash chip
bytewise, you're right.

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

Hi Elmar,

On 12.01.2016 21:48, Elmar Stellnberger wrote:
> I have just tested this utility:
>
> ./msecli -U -i ../opt/frimware/MU02 -m BX100
> ./msecli -L
>
> did work as expected (flashing the firmware and listing the firmware
> status of the device) besides the many other useful options it offers
> apart from flashing the firmware (debug-log, secure-erase, ... )
>
> ./msecli -D -n /dev/sde ... did print a success message for a clean
> new drive from factory but no more information

Do any of the commands mention the name or manufacturer of the flash
chip where the firmware is stored?

Regards,
Carl-Daniel
> Am 2016-01-12 um 18:02 schrieb Luc Verhaegen:
> > /sbin/msecli is where the magic is, and strings shows that that is
> > filled with a load of atapi/smart stuff.
> >
> > Luc Verhaegen.

[Carl-Daniel Hailfinger]

On 12.01.2016 20:57, Stefan Tauner wrote:
> On Tue, 12 Jan 2016 18:47:43 +0100
> Elmar Stellnberger <[e-mail]> wrote:
> > I would love to see HDD/SSD 
> > firmware flashing being supported by flashrom through some more SATA 
> > controllers.
> > Unless it supports at least some kind of addressing I don't deem it
> > within the scope of flashrom. Just reading a complete file and piping
> > it into an API (which library do they use BTW?) is nothing exciting that
> > requires the whole infrastructure of flashrom.
> > By addressing I mean e.g. a way to write only part of the underlying
> > flash memory.

We do support some PCIe based SSDs with Marvell controllers (see
satamv.c), but in that case it's the SATA host controller (which is part
of the PCIe SSD), not the device behind a SATA interface.

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

On 13.01.2016 02:30, Elmar Stellnberger wrote:
> Am 2016-01-12 um 23:50 schrieb Carl-Daniel Hailfinger:
> > Do any of the commands mention the name or manufacturer of the flash
> > chip where the firmware is stored?
>
> My idea was to let msecli collect debug information in this case:
> > sbin/msecli -P debugBX100.zip -n /dev/sde
> > zip file created ...
> > .... success
>
> ** output: see for the attachement
>
> Maybe you can analyse the binary dump for debugging by strings or so.
>
> also of interest:
> > sbin/msecli -C -i -n /dev/sde >identity-data
>
> msecli -D ... gives no useful information
> msecli -G / -m / -Z ... is not supported by BX100

AFAICS this SSD uses the "ATA Download Microcode" command. On Linux, you
can probably use
hdparm --fwdownload
to update the firmware of your SSD. No warranty, though, and I have no
idea if you can use the firmware image as-is or if you have to
patch/edit it first.

This also means flashrom is not the right tool for your SSD.

Regards,
Carl-Daniel

[Elmar Stellnberger]

Am 2016-01-12 um 23:50 schrieb Carl-Daniel Hailfinger:
> Do any of the commands mention the name or manufacturer of the flash
> chip where the firmware is stored?

My idea was to let msecli collect debug information in this case:
> sbin/msecli -P debugBX100.zip -n /dev/sde
> zip file created ...
> .... success

** output: see for the attachement

Maybe you can analyse the binary dump for debugging by strings or so.

also of interest:
> sbin/msecli -C -i -n /dev/sde >identity-data

msecli -D ... gives no useful information
msecli -G / -m / -Z ... is not supported by BX100