New sonic-buildimage images for Broadcom DNX ASIC family. #7598
Conversation
judyjoseph
requested review from
jleveque,
lguohan,
qiluo-msft and
xumia
as code owners
|
@yxieca to take a look |
|
is this a complete pr, do we need to build a different syncd docker on dnx platform. My idea here in this PR was to create new sonic-buildimage-dnx targets for dnx platform, but internally use the same syncd dockers. I use this compile time flag ASIC_FAMILY to decide on which saibcm debian package to be selected during build process. I didn't see a particular use of creating a new docker per ASIC family, as there are 3 dockers we have to duplicate per asic family. But let me know your thoughts. |
|
Can we try to build both DNX and XGS in the same build pass? in order to do this, any module requires dnx target will have to build dnx target explicitly and named accordingly. Then in the end, we could build dns/xgs target without having to start from scratch. The dnx installer will have a different name too. @lguohan , @yxieca Could you take a look. I have taken in this suggestion and building both xgs and dnx image in the same build, have added more implementation/verification details in the conversation section in the PR. Please share your comments. @xumia, also share if there needs to be updates for enabling the cache for new docker/deb components and buildimage targets, |
Thanks for the suggestion Ying, I see you point that it will be good to compile the dnx platform along with the sonic-broadcom image as every compilation cycle is 7-9 hrs. To do this I will create separate syncd-dockers for dnx platform family as Guohan suggested earlier as well. |
judyjoseph
force-pushed
the
buildimage-dnx
branch
from
482d96f to
526d4cf
Compare
judyjoseph
changed the title
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…ker-sycnd-brcm-dnx. Add the respective saibcm dependency in the docker-sycnd-brcm/-dnx
…msi flag. Serialize the docker-syncd-brcm and docker-syncd-brcm-dnx builds
…s different per MACHINE_ type are save separately and copied per TARGET_MACHINE type during build process.
1. Make a common for loop in slave.mk for _MACHINE and _DEPENDENT_MACHINE
2. cleanup the startup scripts correctly now that we creat broadcom_syncd.sh and broadcom-dnx_syncd.sh
3. Remove the close dependency for platform_conf file in onie-mk-demo.sh. In the installer too this file presence is checked before using
( https://github.com/Azure/sonic-buildimage/blob/3ea3a5c8c137969fc758655087607e655b8f404b/installer/x86_64/install.sh#L568)
With this change, the symbolic link created earlier platform/broadcom-dnx --> platform/broadcom is not needed anymore.
… add as a submodule @ platform/broadcom/saibcm-modules-dnx The submodule will be used to create the DNX package : debs/buster/opennsl-modules-dnx*.deb package. Additional fixes in docker*dnx.mk files.
This is no more needed as we have a separate submodule saibcm-modules-dnx for the DNX ASIC family.
platform/broadcom/saibcm-modules --> builds opennsl-modules*.deb platform/broadcom/saibcm-modules-dnx --> builds opennsl-modules-dnx*.deb
This version numbering will follow the SAI version.
judyjoseph
force-pushed
the
buildimage-dnx
branch
from
fe38769 to
21fb001
Compare
| TARGET_PATH="$(TARGET_PATH)" \ | ||
| ./build_image.sh $(LOG) | ||
| # Build images for the MACHINE, DEPENDENT_MACHINE defined. | ||
| $(foreach dep_machine, $($*_MACHINE) $($*_DEPENDENT_MACHINE), \ |
There was a problem hiding this comment.
We can improve it to build the two images in parallel, it increases about 20 minutes in PR build.
2021-06-19T06:33:00.3974964Z [ building ] [ target/sonic-broadcom.bin ]
2021-06-19T07:29:38.9766316Z [ finished ] [ target/sonic-broadcom.bin ]
But it is not a block issue, we can improve it later.
There was a problem hiding this comment.
Sure thanks @xumia will raise this as a follow on PR -- to build both images in parallel.
…ild fail when packages.json is not generated (#8044) After #7598 the packages.json generation is broken. This change fixes it make the whole build fail in case generation failed. Signed-off-by: Stepan Blyschak <[email protected]>
…ild fail when packages.json is not generated (#8044) After #7598 the packages.json generation is broken. This change fixes it make the whole build fail in case generation failed. Signed-off-by: Stepan Blyschak <[email protected]>
…7598) Introduce new sonic-buildimage images for Broadcom DNX ASIC family. sonic-broadcom-dnx.bin sonic-aboot-broadcom-dnx.swi How I did it NO CHANGE to existing make commands make init; make configure PLATFORM=broadcom; make target/sonic-aboot-broadcom.swi; make target/sonic-broadcom.bin The difference now is that it will result in new broadcom images for DNX asic family as well. sonic-broadcom.bin, sonic-broadcom-dnx.bin sonic-aboot-broadcom.swi, sonic-aboot-broadcom-dnx.swi Note: This PR also adds support for Broadcom SAI 5.0 (based on 1.8 SAI ) for DNX based platform + changes in platform x86_64-arista_7280cr3_32p4 bcm config files and platform_env.conf files
Remove the references to file monit_syncd from docker-syncd-brcm-dnx, which got missed as the PR sonic-net#7598 overlapped sonic-net#7676
…ild fail when packages.json is not generated (sonic-net#8044) After sonic-net#7598 the packages.json generation is broken. This change fixes it make the whole build fail in case generation failed. Signed-off-by: Stepan Blyschak <[email protected]>
Why I did it
Introduce new sonic-buildimage images for Broadcom DNX ASIC family.
How I did it
NO CHANGE to existing make commands We use the existing make sonic-buildimage commands as below
The difference now is that it will result in broadcom images for DNX asic family as well. This applies to regular sonic-broadcom.bin and the images based on aboot boot loader sonic-aboot-broadcom.swi
Note: This PR also adds support for Broadcom SAI 5.0 (based on 1.8 SAI ) for DNX based platform + changes in platform x86_64-arista_7280cr3_32p4 bcm config files and platform_env.conf files
The changes in this PR are the following
Note: DBG buid was failing due to existing errors while building sonic-mgmt DBG debian package - hence could not be verified, will take it up if we hit issues later.
How to verify it
Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)