[Help Needed] Need the Definition of DB40 connector of A2 board.

  • Since I updated the bios to 2.09 and meet many flaws. So I decieded to temporarily downgrade my edk2 firmware to 2.04. Because I cannot peform the downgrade via Capsule, I tried the following methods:

    1. Try to switch booting bios to carriar bios (carriar bios can be easily re-programmed using a flash programmer eg. dediprog). But I just failed, No matter how I try setting JP27-JP29, the board always booting from the module bios.

    2. Try to re-program the module bios using DB40 port. Since I can't find anywhere to buy the black version of DB40-HPC for A2 module, I try using a FPC to DIP converter and then connect it to a programmer:

    Unfortunately, the definition of DB40 on A2 board is not included in the module's manual, and it is also not similar to any other board which have DB40 connector like below:

    As of now, what I know is pin1 is SPI_VCC, pin7 is GND, and I also find pin15 is PWRBTN#, apparently not similar to any known document.

    And I also can't determine the spi flash pins using a multimeter. (There's no direct connection between the SPI Flash chip and the DB40 connector).

    So Who can help me provide the the definition of the DB40 connector of A2 board?

    Thanks a lot.

    At last resort, if there's no other option, I can only desolder the bios chip with my hot air gun, and re-program it using my programmer then solder it back. (I reluctant to try the last way, because it is too dangerous and will lost warranty.) 


  • Hi Sir,


    I attached the line for the user manual of DB40 download



    Best Regards,


  • @Tu Ken Thank you for your quick reply. But the manual from your link is for the green version of DB40 board, It seems that the black version is different? From this manual the pin layout is the same as the photo I post previously, but for my test it is not correct.

    Or could you provide some information about where to buy the black version of DB40-HPC board for A2? I think I need one.

  • @Jiaheng Wang ADLINK sent me a black DB40 board (it's "DB40-HPC") a few months ago and provided me with a preliminary user guide in June which explains the pin layout. Someone should be able to provide you with a copy.

  • @Jiaheng Wang 

    Noticed your problem, let me first check quickly if downgrading from 2.09 to 2.04 can be done through  fwupdmgr under Linux.

    We are also close to releasing an update to edk2 / MMC / BMC to fix several known issues.
    Will get you the manual that Rebbecca mentioned : DB40-HPC.

  • @Ruler of COM @Rebecca Cran Thanks for all your information. I've got the document for DB40-HPC and found that the pin layout is indeed different from the green version of DB40. Now I've successfully re-programmed my bios to 2.04 using my SEGGER J-Link.

    All the elements needed can be easily got on Aliexpress.

    If anyone else only need to re-program your module bios without a DB40-HPC board. I can offer a simple guide.


  • Hi @Jiaheng Wang ,

    Thanks for sharing your experience, that's extremely useful given the instabilities of the current firmware, it allows users to try the one that works best for them without risking to brick their device; that's still an expensive board that nobody wants to turn to paperweight for flashing a bad one!

    While waiting for next week's firmware update, I've ordered an FPC-to-DIP adapter like yours so that if for any reason I cannot manage to boot from the carrier board's SPI after the update, at least I'll have the option to try to flash the module directly.

    For other readers interested in the 40-pin debug connector pinout, I just found it here in the updated DB40-HPC board's manual: https://www.adlinktech.com/Products/Computer_on_Modules/EngineeringTools/DB40-HPC_Debug_Module at page 13. (and it matches the pins you found except that they're numberred from the other direction).

    Is there anything special to be aware of for flashing ? Should I just send the 32 MB image using flashrom to that flash or should I protect certain areas for example ? I saw somewhere else that Rebecca suggested not to overwrite the beginning. We could for example imagine that the ethernet MACs or the board's serial number or anything else is stored in the flash and needs to be protected.

  • @Willy Tarreau If you use the 32MB image, you can just overwrite the whole chip, no worries.

  • Thank you!

  • Newest set of firmware here : https://www.ipi.wiki/pages/ampere-altra-developer-platform-download

    Note that AADP and AADK share same firmware AADP is AADK with a chassis around it.

    MMC 2.09
    BMC 2.06

    After you applied this update you will be able to activate the SPI flash on the carrier in case you would ever brick the module SPI flash. The SPI flash on the carrier is socketed so you can simple flash it externally. For a pristine flash part you will need the 32 MB version.

    EDK2 with BMC update activates the SSIF interface for ipmitool communiction with the BMC. 



  • @Ruler of COM thank you! I'll try it this morning and let you know how it goes. Many thanks!

  • @Ruler of COM great news, I could flash the on-board SPI using my buspirate board + flashrom and moving JP27 to 2-3.

    Now the board boots again (and boot quite faster than it previously did). The machine booted correctly at 2.6 GHz so at first glance I'm not affected anymore by the previous issue that made me need to upgrade. Thus I'm now running MMC 2.09 (flashed via IPMI) and EDK2 (flashed using an external SPI programmer). I have not updated the BMC, I don't know its version (I preferred not to brick everything at once).

    I have one comment for the mainboard manual: there's no indication of the SPI NOR polarity on the socket :-)  I had to figure it using an ohm-meter to look for GND. It would be nice to at least mark it in the manual!

    For those reading this, Pin 1 is towards the board's center, close to the "COM-HPC" marking on the board.

    Now I'll see if I can reprogram the on-module EDK2 from the UEFI shell booted on the on-board SPI, I don't know, this will be a surprise :-)

    Thanks a lot!

  • So as indicated in the 2.3 GHz thread, finally after another reboot the machine is again at 2.3 GHz instead of 2.6 once reverted to EDK2 So there's clearly a difference between 2.04 and 2.09 that is causing this problem and that 2.09 fixed. I'll probably program 2.09 on the carrier board so that using JP27 I can use it, and revert to 2.04 in case it bricks again.

  • @Willy Tarreau Hi I forget to tell you that after trying many times of different version of EDK2, I figured out that geerlingguy may be using the version of 2.06. Currently I'm using the 2.06 edk now, and it does not have the frequency issue. Though it has some minor issues on IPMI, but stable enough to use if you are more concerned about the frequency.




  • Where did you find 2.06 ? I'm only seeing 2.04 on github and 2.09 on the download page.

  • @Willy Tarreau If you go down the page far enough, there's a release from July 2022, v2.06.100.00:

    "Update CRB code to V2.06.100-ampere."

  • @Rebecca Cran Thank you Rebecca. I may give it a try next week. For now I've left the legacy version on the module with MMC 2.09 that checks JP27, and EDK2 2.09 on the carrier board. It boot super slowly (as previously) but I have full frequency. Next time it refuses to boot, I'll just have to move JP27 back to 1.2 to restart from 2.04 on the module. I can try to flash 2.06 on the carrier board to see if it's better.

  • @Willy Tarreau It would be nice if there was an official build with more verbose logging enabled (DEBUG_INFO at least).

  • @Willy Tarreau I have an idea about your slow boot issue. There's basically a race condition between the BMC and UEFI: UEFI wants to use SSIF to read information about the BMC, but it requires that the BMC has booted. I think the SSIF specification says to retry 260 times with 60 milliseconds between retries, which ends up being a really long time if you have lots of information you're trying to read, and there's no mechanism to tell the SSIF driver to give up.


    Of course this doesn't apply unless you pull the power to the whole system each time, causing the BMC to boot up when you plug the power back in.

  • I timed this. When power is applied for some time to the carrier, meaning BMC  has booted, and than boot up the time to the ESC to UEFI menu is around 43 sec. 

    If I do a power disconnect-reconnect, meaning BMC is booting almost same time as I start the system than time is the same 43 seconds.

    The long boot time as we obeserved ourselves happens when using the latest edk2 that is the first version enabling SSIF to BMC. If the BMC in that case is not update to latest firmware 2.06 than communication fails and than you wait for a time out during edk2 exiection. We saw up to 40 seconds on top of the 43 seconds.


  • 1 / 2
  • 2
Please login to reply this topic!