Rare project developers

[Gawen Davey <>]

Hi Alex,

At some point, I will have the Thrift bindings done. The reason they aren't in the beta are that (keeping in mind this BSP is built from scratch), is that there's a bit of engineering to do to understand the build infrastructure around it (I don't want to do just a copy and paste job), and wire everything together. There's some bits missing with respect to grabbing the PSU information, so it wouldn't be complete as the BSP stands at the moment. I hadn't quite gotten around to see if I could have empty services, or simply not attach any RPC processors when the SDE/BSP asks for it, but if you're actually using Thrift in RARE then I think finishing it is work that should be done.

However If you'd be happy with empty Thrift services for testing I can look at it next week.

Having said that, I really want the BSP to be feature-complete when it is released, and that the build semantics do not differ at the point of use from pervious BSPs.

Gawen

---

From: Alexander Gall <>
Sent: 23 June 2022 07:38
To: Gawen Davey <>
Cc: Frédéric LOUI <>; <>; <>; Alexander Jeffries <>
Subject: Re: Access

 

Hi Gawen

On Wed, 22 Jun 2022 10:44:10 +0000, Gawen Davey <> said:

> Oh and P.S.
> I got so excited about the efuse issue that I neglected to tell you that you should build the sde with thrift disabled, as the BSP doesn't
> currently have any bindings. You can't do this via the interactive p4studio prompt, but you can do so via p4studio profile apply $
> {path_to_profile}​

When you say "currently", you mean that this will not be necessary in
the final (or a later) version?  We use a build system not based on
p4studio where we create separate packages for each BSP we support
(that's for the official RARE releases, csaba is using p4studio for
testing right now). They share all platform-independent components,
e.g. the bf-drivers package. In this case, we need to build a separate
version of that package with thrift disabled. That's not a problem but
we would like to avoid it as much as possible.

--
Alex

> The profile I used yesterday was:

> global-options:
>   asic: true
> features:
>   drivers:
>     bfrt: true
>     grpc: true
>     thrift-driver: false
> architectures: []
> -----------------------------------------------------------------------------------------------------------------------------------------------
> From: Gawen Davey <>
> Sent: 22 June 2022 10:08
> To: Frédéric LOUI <>; Alexander Gall <>
> Cc: <>; <>; Alexander Jeffries <>
> Subject: Re: Access
 
> Yes, It will go on the portal. But it's beta, not ready for general release.

> With respect to the latest error, looks like SDE 9.9.0 removed some code that handled a case where a part number is not properly burned into
> the "efuse". This is not something that can be fixed by the BSP, and requires a patched bf-drivers package. So the SDE version as it comes from
> Intel won't ever work.

> I've got a script as a workaround. It unpacks the SDE and bf-drivers package, applies the necessary patch, and packages everything back up
> again. It expects the original SDE tarball to be in the same directory as itself, and will replace it in-situ.

> Probably don't need to create an entire SDE tarball, so the last three lines are probably unecessary.

> In any case, I've raised a ticket with Intel, but this certainly sets back my plans. I don't want to add more scripts and instructions to our
> documentation and downloads, so nothing will be going on the support portal until I hear back from Intel.

> #! /usr/bin/env bash

> set -eE

> script_dir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"

> cd ${script_dir}

> tar xvf bf-sde-9.9.0.tgz
> cd bf-sde-9.9.0/packages
> tar xvf bf-drivers-9.9.0.tgz
> rm bf-drivers-9.9.0.tgz

> patch -p0 <<'EOM'
> Index: bf-drivers-9.9.0/src/lld/lld_efuse_tof.c
> ===================================================================
> --- bf-drivers-9.9.0.orig/src/lld/lld_efuse_tof.c
> +++ bf-drivers-9.9.0/src/lld/lld_efuse_tof.c
> @@ -117,6 +117,15 @@ int lld_efuse_tof_load(bf_dev_id_t dev_i
dev_p-> efuse_data.voltage_scaling =
>        extract_bit_fld_128(hi64, lo64, (245 - 128), (243 - 128));
 
> +    /* If either pipes or ports are disabled in efuse we'll pretend
> +   * this is a tofin-small */
> +  if ((dev_p->efuse_data.pipe_disable != 0) ||
> +      (dev_p->efuse_data.port_disable_map_lo != 0)) {
> +    /* This is a temporary hack since some of the Tofino lite chip dont have
> +       have the chip part number burned correctly in the efuse */
> +    dev_p->efuse_data.chip_part_number = BFN_PART_NBR_BFNT10032D;  // T-3.2-Half
> +  }
> +
>    if (dev_p->efuse_data.chip_part_number == BFN_PART_NBR_BFNT10032D) {
>      // T-3.2-Half
>      uint64_t p = dev_p->efuse_data.port_disable_map_lo;
> EOM

> tar cvf bf-drivers-9.9.0.tgz bf-drivers-9.9.0
> rm -rf bf-drivers-9.9.0
> cd ${script_dir}
> rm bf-sde-9.9.0.tgz
> tar cvf bf-sde-9.9.0.tgz bf-sde-9.9.0

--
Alexander Gall, Network

SWITCH
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 15 22
https://switch.ch https://swit.ch/linkedin  https://swit.ch/twitter