Conversation
|
I deviated from the norm with including content in an intermediate file (i.e. imx95/fuses includes bsp/fuse instead of the head.rst manual). The goal/advantage of this would be that the leaf file is less cluttered and does not include multiple pieces of content for the same logical section. |
ymoog
requested review from
BHahn42618,
Varakala02,
cstoidner,
jremmet and
tremmet
| u-boot=> fuse read 40 6 | ||
| Reading bank 40: | ||
|
|
||
| Word 0x00000006: 0300BC9A |
There was a problem hiding this comment.
We should add a warning about partial register writes here and remember which is the dominant state used for the fuses.
There was a problem hiding this comment.
Sorry, I don't fully understand what you mean and how you envision the result.
With partial write you mean e.g. fuse prog 40 6 0xC9A? What should the warning say; should we advise against partial writes?
Regarding the dominant state: Do you mean state for each fuse i.e. 1 is fuse blown?
There was a problem hiding this comment.
Yes, think you need to read the fuses and than mask your changes in and than write it. Think the customer should know that he can only alter the fuse in one direction once.
There was a problem hiding this comment.
I experimented a bit with trying to mask values and did not get it to work. Once a word is written it looks to me like it cannot be altered. Even if not every fuse is blown within the word. NXP supplies the ELE API documentation, but that did not help me in identifying the problem.
Shall we assume single write only until we figure out if individual fuses can be blown after initial write?
There was a problem hiding this comment.
Yes, I would say we should assume that and add a warning about that.
The i.MX 95 features groups of programmable fuses. These can be locked additionally. For an initial section, keep it simple and focus on translating fuse positions from Reference Manual to U-Boot API. Signed-off-by: Yannic Moog <y.moog@phytec.de>
| (Chapter 5 Fuse Map), :math:`b` is the bank and :math:`w` is the word U-Boot | ||
| expects as arguments to fuse commands. | ||
|
|
||
| MAC_ADDR example; Note that the MAC address fuses will already be blown for |
There was a problem hiding this comment.
I would prefer an info box here that the MAC is already burned.
|
|
||
| All of the ``General Purpose fuse for customer use`` fuses are word aligned so | ||
| no care needs to be taken in regards to bit positions within a word. | ||
| Example of burning GPR4_CFG6 fuses (Fuse index 12224). |
There was a problem hiding this comment.
Maybe write here explicit that Phytec does not write those fuses and that they can be used by customers.
| u-boot=> fuse read 40 6 | ||
| Reading bank 40: | ||
|
|
||
| Word 0x00000006: 0300BC9A |
There was a problem hiding this comment.
Please describe that the 3 is the number of macs. And why it needs to be 3. As far as I understand it is not even clear that this needs to be 3 and not 7 or something else entirely (if we also need to count potential adapter cards like WLAN or pcie to ethernet), as U-Boot uses offset +3 and +6 for the other interfaces and will throw errors when number of macs is set to 3. For imx94 there is a mac address offset table in U-Boot (which I do not really understand). For imx95 this is not provided. The only thing that I take from this table is, that number of macs might not equal number of ethernet interfaces. I think we should create a support ticket with NXP and ask them what needs to be set there and why, as I also did not find sufficient information on that subject.
There was a problem hiding this comment.
I don't think this is relevant at all. As Teresa already mentioned, the MAC addresses are fused already by us, so discussions about what NUM_OF_MACS should be fused to distracts from the point of explaining how the process of fusing works for the i.MX 95.
4 participants
The i.MX 95 features groups of programmable fuses. These can be locked additionally. For an initial section, keep it simple and focus on translating fuse positions from Reference Manual to U-Boot API.