1. tftpboot firmimg.d7
2. go 0x81000000
3. bootm

(0x81000000 is the address where tftpboot load the fw)

Enjoy!
But now I 100% convinced that EMMC is bad, and this is the root of the problem




[SH7757 ~]$ dd if=/dev/mmcblk1 of=/dev/mmcblk0
sh_mmcif: Cmd(d'18) err
mmcblk0: retrying using single block read
Mar 20 11:34:20sh_mmcif: Cmd(d'17) err
(none) kernel: mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
sh_mmcif: Cmd(d'end_request: I/O error, dev mmcblk0, sector 32
18) err
Mar 20 11:34:20 (none) kernel:sh_mmcif: Cmd(d'17) err
mmcblk0: retryimmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
ng using single end_request: I/O error, dev mmcblk0, sector 33
block read
Mar 20 11:34:20 (none) kernsh_mmcif: Cmd(d'17) err
el: sh_mmcif: Cmmmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
d(d'17) err
Maend_request: I/O error, dev mmcblk0, sector 34
r 20 11:34:20 (none) kernel: mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
Mar 20 11:34:20 (none) kernel: end_request: I/O error, dev mmcblk0, sector 32
Mar 20 11:34:20 (none) kernel: sh_sh_mmcif: Cmd(d'17) err
mmcif: Cmd(d'17) err
Mar 20 11:34:20 (mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
none) kernel: mmend_request: I/O error, dev mmcblk0, sector 35
cblk0: error -84 sending read/write command, response 0x0, card status 0xd40
Mar 20 11:34:20 (none) kernel: end_request: I/O error, dev mmcblk0, sector 33
Mar 20 11:34:20 (none) kesh_mmcif: Cmd(d'17) err
rnel: sh_mmcif: Cmd(d'17) err
Mar 20 1mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
1:34:20 (none) kend_request: I/O error, dev mmcblk0, sector 36
ernel: mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
Mar 20 11:34:20 (none) kernel: end_request: I/O error, dev mmcblk0, sector 34
Mar 20 11:34:20 (none) kernel: sh_mmcif: Cmd(d'17) err
Mar 20 11:34:20 (none) kernel: mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
Mar 20 11:34:20 (none) kernel: end_request: I/O error, dev mmcblk0, sector 35
Mar 20 11:34:20 (none) kernel: sh_mmcif: Cmd(d'17) err
sh_mmcif: Cmd(d'mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
17) err
Mar 20end_request: I/O error, dev mmcblk0, sector 37
11:34:20 (none) kernel: mmcblk0sh_mmcif: Cmd(d'17) err
mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40

Mar 20 11:34:2end_request: I/O error, dev mmcblk0, sector 38
0 (none) kernel: end_request: I/O error, dev mmcblk0, sector 36
Mar 20 11:34:20 (none) kernel: sh_mmcif: Cmd(d'17) err
Mar 20 11:34:20 (none) kernel: mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
Mar 20 11:34:20 (none) kernel: end_request: I/O error, dev mmcblk0, sector 37
Mar 20 11:34:20 (none) kernelsh_mmcif: Cmd(d'17) err
: sh_mmcif: Cmd(mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
d'17) err
Mar end_request: I/O error, dev mmcblk0, sector 39
20 11:34:20 (none) kernel: mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
Mar 20 11:34:20 (none) kernel: end_request: I/O error, dev mmcblk0, sector 38
Mar 20 11:34:20 (none) kernel: sh_mmcif: Cmd(d'17) err
Mar 20 11:34:20 (none) kernel: mmcblk0: error -84 sending read/write command, response 0x0, card status 0xd40
Mar 20 11:34:20 (none) kernel: end_request: I/O error, dev mmcblk0, sector 39
dd: writing '/dev/mmcblk0': Input/output error
33+0 records in
32+0 records out
16384 bytes (16.0KB) copied, 0.291646 seconds, 54.9KB/s
[SH7757 ~]$

So to elaborate on my previous post, I hooked up the com port on my new dell server off ebay (pastebin XqFcZ1GR). It does boot up to a small linux distro. I haven't done a lot yet, now I want to get the network online so I can use tftp/ftp and otherwise try to mess with that server without (hopefully) corrupting it too.

What you and I have been struggling with is we're already in a broken uboot environment, and we don't get all that extra emmc functionality. With this new test bed I have that same shell the others with a 'partially broken' idrac have.

Still this is encouraging to me, and there's a whole new are for me to explore now. I wish stuff didn't take so long to ship from china.

Zitat von ldv im Beitrag #76

---

1. tftpboot firmimg.d7
2. go 0x81000000
3. bootm

(0x81000000 is the address where tftpboot load the fw)

Enjoy!

---

Yes you are! )) But because the OS is loaded from RAM it works only until the next reboot. But be careful! Yesterday I bricked it again. What I did, was trying to upgrade FW. Don’t ask me why I decided to takeaway 32Gb SD card and put a 1Gb SD card instead. SD card size should be the same size as the EMMC or more. So when I ran fwu sd and then fwu update it somehow erased the SPI flash and now there’s no u-boot anymore. My guess is that when you run fwu update, it creates partition layout on SD card and then copies U-boot.bin to it and then to SPI. May be I’m wrong, but otherwise I don’t understand why there are u-boot partitions on SD/EMMC If you run util flashinfo you can see all this partitions and their content.
So I need to reprogram the SPI memory using external chip programmer. At least this time I now how to bring the iDRAC to work) And this time I’m going to try to replace the eMMC chip too.

Thats amazing!!!! If I understand correctly, since the idrac is its own CPU/OS, once we get it loaded it will stay in the background as long as the system is plugged in? So that means no more crazy fan noise, no more 15-minute-long boot/reboot times! We can even shut down the main system (Windows), and idrac will keep working as long as the power cable is plugged in. If this is indeed the case then this is HUGE! It makes the system useable again!

So you've made some solid progress @ldv. I haven't done the dd approach, frankly I wouldn't know where to dd it to, I don't want to mess with my 'good' dell more than I need to. However I think I'll be able to accomplish the same thing. I used: tftp -p -r mmcblk0.bin 192.168.0.243 -l /dev/mmcblk0 to write the idrac block device to my laptop (.243) running the free SolarWinds tftp server.

I also thought I'd point out that I also found the working boot log full of good information.

Notably this:
Dec 31 18:00:11 (none) kernel: Creating 9 MTD partitions on "m25p80":
Dec 31 18:00:11 (none) kernel: 0x000000000000-0x000000080000 : "u-boot1"
Dec 31 18:00:11 (none) kernel: 0x000000080000-0x000000100000 : "u-boot2"
Dec 31 18:00:11 (none) kernel: 0x000000100000-0x000000110000 : "env1"
Dec 31 18:00:11 (none) kernel: 0x000000110000-0x000000120000 : "env2"
Dec 31 18:00:11 (none) kernel: 0x000000120000-0x000000130000 : "fru"
Dec 31 18:00:11 (none) kernel: 0x000000130000-0x000000140000 : "res1"
Dec 31 18:00:11 (none) kernel: 0x000000140000-0x0000001c0000 : "tracebuf"
Dec 31 18:00:11 (none) kernel: 0x0000001c0000-0x000000340000 : "lcl"
Dec 31 18:00:11 (none) kernel: 0x000000340000-0x000000400000 : "res2"

For those of us using a chip programmer to recover our idrac on a regular basis it's very nice to know the boundaries of each section of that chip. I took my original dump file, loaded it into hexedit, used the select region command (ctrl-e) to select each region (110000-11ffff for example) and then save that section in it's own .bin file. Now if I want to write back a 'good' uboot, I just need to concatenate the 'good' uboot(s) with my original fru and res .bin files (the fru contains the cn and dell ID's, and the res has the mac addresses, unique data I'd like to keep on the right motherboard).

I haven't actually burned that back yet (having just pieced that together today) but if I don't hit some kind of crc value I have to try to recalculate then I'm hoping to be able to take the good uboot's and put them on other 'bad' eproms without wiping out those board's ID's (or worse ending up with multiple servers with the same mac address).

Once I can get a good image I'll load up my bad board and see if I can get your tftp trick to work. I'm pretty excited about that too.

So I think I have everything I want from the good board. I was able to open the .bin image in winimage and it shows all the same partitions I saw in the emmc. It gives me hope I can write that back block by block and have the same image.

I'll spend tomorrow soldering headers onto the jtag port/console port of the 'bad' board then go through the tedious motherboard swap. Once I get the bad one in there I'll start by doing the tftp boot thing you've shown us.

After I wrap my head around that I think I'll spend some time trying to figure out the emmc jtag and see if I can find a way to write the .bin back to the chip without using idrac. Maybe if the bad area isn't actually relevant I can get a functional emmc. I'm thinking maybe the dell upgrade just fails and leaves an incomplete image, but if I can write around the bad areas maybe it'll end up being in one of those areas that's either redundant, or mostly blank.

Alternately I'm wondering if there isn't a way to manipulate the settings in the idrac eprom to boot from the sdcard so that it's persistent between boots. I notice there's also a section in there for an nfs boot, if I could get it to consistently boot the image from nfs that'd be fine too since I have a couple nas devices that support nfs.

״Alternately I'm wondering if there isn't a way to manipulate the settings in the idrac eprom to boot from the sdcard so that it's persistent between boots. ״ @willard
It definitely possible. Actually, that’s what I’m going to try first, before the attempt to replace the EMMC chip.
I think it can be done by setting the environment variables. What I figured out, is that these variables can be not only a “key = value “ but also a “key={script }” type.
So you can try to run following(excuse me if the syntax is wrong, since I bricked my iDRAC again I can’t check it at this moment , so I’m typing it right out of my memory):
1. To set SD as boot device permanently
set bootcmd ‘sd_boot’
saveenv

2. To boot from tftp permanently
set bootcmd ‘tftpboot -f firming.d7; go addr 0x81000000; bootm;’
saveenv

I finally installed my dysfunctional board. I want to write back the idrac7 firmware, because the idrac8 that's on there's probably not a great place to start (that was an attempt to load the latest firmware).

This board has always been really hard to write to the spi eeprom. So I'm struggling with that. If I can get the uboot back to a reasonable version then I'll see if I can get the sdcard written and modify the boot as you describe. I'm not sure if this chip just hugs the board tighter and it's harder to get a good clamp on all 8 pins, or if it's somehow the chip is degrading over time (or maybe oxidation on the pins or something).

I'm debating whether I want to try to pull that chip and put a new eprom on, but then I'm introducing another variable to the problem.

Looks like iam not alone with idrac problem. I also have a 720XD with death idrac and/or lifecycle controller. Total same error/state like in the 1st post. I hope your machine Will be fixed and then i Will able to copy, try your method :)

Having just pulled a R720 out of the trash I find it has a busted iDRAC7 too. Runs great, sounds like a banshee, takes 8 minutes to boot, and requires user input(F1) to exit POST but it runs. I'm a hardware guy and really want to fix my embedded iDRAC too. Haven't spent a penny on it yet and don't intend to, lol. Reached out to some embedded guys on LinkedIN, a few may have been on the Avocent/Emerson/Vertiv team who actually designed it. Hopefully, one will respond here with something amazingly helpful.

Personaly i do a half solution. I place a teradici tera2 Workstation card to the dell 720XD with an old Nvidia Quadro NV295. Now quadro connected to the teradici tera2 PCOIP card and i can press F1 remote like in idrac vnc… i know its a half solution but better than nothing and dont need to listen the machine :)

Or, you could buy tiny Arduino board to emulate a keyboard and send the 'F1' keystroke once every five minutes. Back in the day they used this method to guess the four digit pin that could be installed on older Mac BIOSs. Example:www.sparkfun.com/tutorials/337

Hi to All. I read the full discuss. And I might be at the wrong topic but my need repair "process" should be the same. I have a Google TSA T4, it is the YELLOW GOOGLE : Dell R720xd
The issue lock to "BOOT password" or stuck the boot process to "boot password protected"(This is not the password to enter in bios). Mean it boot correctly but alt to a password that will allow you to continue to boot to media.
So as long as I cannot bypass that "BOOT password", the server will go nowhere. Google 3rd bios deactivate the password switch on motherboard(no clear password possible). Goggle is not given Password (for protecting customer data: there is no hard drive...).

I just need it to boot normally and bios update to a regular Dell R720 bios.
How can I "SPI Flash" the Bios? Where are located the component (SPI, UART, Bios...) and what tools need?
Any help appreciate!

For precision ON my issue:
I need to "Force flash" a new bios to the motherboard. The motherboard is stuck at "System password" not stuck at "Bios access". Yea I might have given a half good explanation by saying "BOOT password". https://www.dell.com/community/Laptops-G...gs/td-p/4599673

The issue, I am unable to remove or reset the password: Google 3rd bios disable the physical "CLEAR Password" switch on the motherboard. I just want the motherboard to boot normally, I don't even need to access to the bios... By booting normally I will be able to boot to a USB dos to update the bios.
So if no normal "boot" then "Force flash"!!!

Thank you!!