d'oh - thought you were on a 7450 for some reason. Indeed if you have an icx7150 variant, they all have the same boot process/loader/flash locations. glad you got it figured out!Appreciate the offer and the help you've provided to the community, but wanted to try to do this myself as a learning experience. Fortunately, I did not learn how to brick a switch, but rather how to manually load the bootloader code, which will be a valuable skill as I manage a fleet of these.
I first stumbled across the 6430/6450 steps, but instead followed the 7150-C12P recover that was documented in the end of Nov, in which you used:
##RECOVER
##this example uses the mnz10114 bootloader from the 8080 codetrain/zip
tftp 0x80000000 mnz10114.bin
sf probe 0:0
sf erase 0 +11F3D8
sf write 0x80000200 0 0x11F3D8
##VERIFY
sf probe 0:0
sf read 0x80000000 0 100
md 0x80000000
The version of uboot on this switch is exactly the same as that 7150-C12P, the only difference being that this is it's bigger brother (7150-48zp). So I'm leaning toward that being the more correct approach in my case. I had gotten as far as loading the mnz10114.bin file from TFTP/USB into memory, and validating that it wrote successfully. I also saw both sflash chips:
u-boot> sf probe 0:0
Access set to SECONDARY FL..
SF: Detected MX25L6405D with page size 256 Bytes, erase size 64 KiB, total 8 MiB
u-boot> sf probe 0:1
Flash set to PRIMARY FL
SF: Detected MX25L6405D with page size 256 Bytes, erase size 64 KiB, total 8 MiB
u-boot>
Following your example of the C12P, you erased the first MB (+11F3D8) on secondary flash (0:0) starting at the beginning (0) and just copied over the ram contents that were populated from the bootloader file loaded from TFTP. That all seems fairly straightforward. I took a leap of faith and performed the exact same steps to write the new bootloader onto the start of secondary flash, crossed my fingers, and it booted into the Brocade 08080 bootloader ca. 2018. From there, re-applying the official boot image and finally full Brocade OS was trivial.
I am still getting the device key or cert file not available errors, even after issuing sz disable from conf t and reloading. Otherwise, life is good, and I will continue to upgrade this to the most recent UFI codebase and maybe even open up telnet to the Linux environment as you've described.
Thanks again for all you've done for the community, and add 7150-48zp to the list of hardware that these steps are known to work for.
the key thing to note is the brocade-shipped bootloader file has a bunch of metadata at the beginning, and if you write that to flash, it's not gunna boot. You'll note in my instructions, you copy in the whole bootloader file to 0x80000000 in RAM, but then when writing to SPI flash, the RAM address you tell it to pull from is 0x80000200 - skipping the first 0x200 bytes of the copied-in brocade bootloader, so it starts writing from the actual bootloader start. One detail is this offset/metadata size could change at anytime (totally up to ruckus) which is one of many reasons I'm weary to give out instructions instead of doing it myself, I don't want people to brick their stuff if the offset changes and they don't know how to verify it. It's pretty obvious when opening the bootloader in a hex editor like HxD, it's the metadata, empty space and then the actual bootloader start, which for these ARM devices typically always has "EA" at the end of the first row of bytes:

so indeed in this example the offset is still 0x200 bytes
the other big thing is verifying where in SPI the actual bootloader needs to be written to. this is almost always at the very beginning, but as usual it's subject to change on different platforms so it needs to be verified first. typically to verify you would read the very first couple hundred bytes of SPI flash, and see if it looks like the very beginning of a bootloader. If it doesn't, that's not where you should write it. it should look similar to the starting bytes of our example bootloader above:
Code:
##to read boot flash for sanity check
(0:0 is primary boot flash, 0:1 is secondary)
sf probe 0:0
sf read 0x80000000 0 100
md 0x80000000

if you get something close to that, you know the bootloader is supposed to be written right at the start of said SPI and you're good to go