ODMDATA Value Clarification


In parsing out the ODMDATA value that is in the conf file there seems to be some disagreement in the documentation and also in parsing the value out itself:

The value in p2972-0000.conf.common is


If I parse this out based on the info in the adaptation guide:

# Bits 31:27 control HSIO-PCIE-XBAR configurations for controllers 4-0 (where is controller 5?)
# Bits 24:23 control UFS configurations
# Bit 22 controls SATA 
# 2822 breakdown of settings
# 0x919 --> 0b10010 || 0b11 || 0b0 
# pcie-xbar-8-0-1-0-2 --> C5 = 8 lanes, C4 = 0 lanes, C3 = 1 lane, C1 = 0 lanes, C0 = 2 lanes?
# This doesnt align with the P2822 design...C0 should be 4 lanes for the M.2 Key M
# UFS config = Enabled, L10 and L11
# This algins with the 2822 design, L10 is for the UFS card, and L11 is for eSATA
# SATA = disabled, this must be different from the eSATA controller.

There are only 5 bits, but there are 6 controllers - where is the other controller configured? And is it C5 or C0 that is not part of this? The documentation says that this sets the config for controllers 4-0, but that doesnt align with the parsed bits…

The xbar would seem to suggest that it starts with C5, as that is a x8 that is used for the PCIe x16 slot, but then you have to omit C2, and there is no x4 value for the NVMe SSD on C0 anywhere.

I also do not see an 8-0-1-0-4 which is what I would expect based on the way this is documented in the guide.

x8 for C5, x1 for C3 and x4 for C0

According to the guide however, the ‘expected’ value is 0x8190000 - which doesnt make any sense at all for the configuration of the carrier.

Hi dan.binnun,

Sorry that we don’t support to change the uphy lane mapping on xavier. We only support the specific mapping as the one used on devkit

Can you explain the current value at least?

I’m not asking you to help me change anything…I’m asking you to explain the code within the Xavier build file set.

Hi Dan,

Sure. I will share the table of odmdara once later.

Hi Dan,

I think you have mistake here. ODMDATA=0x9190000 indicates 31 - 27 bit -> 0001 and according to the table, the pcie number should be 4-1-0-1-2 and it indicates controller c0~c4. C5 cannot be controlled by odmdata.

If you change 0x8190000, it has nothing to do the 31-27 bit, what you change is bit 24 and it is for ufs configuration but not the pcie xbar configuration.

Hi Wayne,

So is there a 0 before that 919000 hex value? or at the end? I assumed at the end of the value (0x9190 0000). Hence why I thought it was so far off.

If it is actually:

0x0919 0000

Binary = 0000 1001 0001 1001 0000 0000 0000 0000

So bits 31:27 of the bits 31:0 would be 00001 this would be 4-1-0-1-2 for the x-bar config

For C0-C4 that would be PCIe x4, PCIe x1, Not used, PCIe x1, PCIe x2

If that is the case, the documentation is unclear, and in fact does not match the following statement from the adaptation and bring up guide:

ODMDATA = 0x8190000 while flashing for Jetson AGX Xavier carrier board.

In the actual files in the source, this is not the value and a source of confusion.

If C5 is not controlled by ODM data, how is it controlled - I didn’t see a mention of it in the documentation aside from the default x8 mode.

We hooked it up as a x4 interface so I need to understand how that is configured - where is that in the documentation?

ODM data is used only to control XBAR of C0 ~ C4 controllers as some kind of agreement is required among controllers C0 ~ C4 as they all share the same set of PHY lanes. When it comes to C5 controller, it has a dedicated set of 8-PHY lanes (always at its disposal) and hence is not part of XABAR config. As far as your requirement is concerned (based on how I understood it), you are planning to have an x4 interface for C5, well, for that, the default configuration would just work fine as C5 is an x8 controller and it can work with cards with lower width (x4, x2, and x1) as well without any issues.

So to be clear then - there is a LEADING zero omitted in the hex value in the documentation as well as in the configuration file.

The full value is 0x0919 0000

A leading zero is significant here…

Please confirm

edited to avoid confusion, forgot trailing 0

Thanks for the explanation regarding C5 - this would be good to add to the ODMDATA section in the document about adaptation. It is unclear.

Full value is 0x09190000 (I think you missed one zero towards the end)

Yes I did, thank you. Will edit post.