Skip to content

Conversation

@bith3ad
Copy link

@bith3ad bith3ad commented Nov 10, 2025

Hi,

this v2 is based on the review I received on #7453. Unfortunately I couldn't follow the contributors guideline and had to open a new PR because the PR got closed by the bot. Therefore I added the changes but squashed them directly.

Emantor and others added 8 commits November 10, 2025 13:04
The Cortex-A9 inside of the i.MX6Q/D/QP/DL/S/SL/SLL SoCs has no generic
timer support, but all variants should boot with 792Mhz out of the boot
rom. Set the Generic Timer configuration variable to n and implement the
required plat_get_freq() call to support the udelay() calls.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
The i.MX8MP has an OCOTP_CTRL_ADDR field which is 8-bit wide compared to
all other current supported i.MX SoCs. Due to the larger ADDR field all
bits shifted by 1 bit.

Also make some minor style fixes while on it by replacing the mix of
tabs and spaces with tabs-only.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
According the reference manuals the ERROR bit should be cleared by
writing a '1' to the OCOTP_CTRL_CLR register and not by writing to the
OCOTP_CTRL direct.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Check the g_base_addr and g_ocotp before do the first access.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Use the builtin ARMv8a timer instead of assuming that the CPU is running
at 500MHz and the poll takes around ~20us.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
This adds the support to burn fuses on i.MX8M SoCs. This approach assume
that the IPG clock is running at 66.67 MHz which is AHB/2 (AHB max.
clock = 133 MHz). Due to lack of HW I added only the i.MX8M support.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reuse the same write functions as for i.MX8M SoC since they seem to use
the same OCOTP IP core according to the reference manual.

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Reuse the same write function as the other i.MX6 SoCs since
the OCOTP IP is the same. i.MX6ULL just has fewer fuse banks
than i.MX6UL.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
@bith3ad
Copy link
Author

bith3ad commented Nov 10, 2025

Question: Is it really required to keep the 80-char limit?

@jenswi-linaro
Copy link
Contributor

Question: Is it really required to keep the 80-char limit?

Generally, yes, but there are exceptions for prints. Problems with following the limit usually stem from unwieldy local variables. If there's a place apart from prints where you think an exception is needed, feel free to point it out.

@bith3ad
Copy link
Author

bith3ad commented Nov 11, 2025

Okay thanks and good to know. I asked because most projects have lifted this hard requirement to 100-chars.
E.g. the lines, the CI is complaining about, could be split of course, but for the sake of readability I would rather keep them as their are right now.

@jenswi-linaro
Copy link
Contributor

Okay thanks and good to know. I asked because most projects have lifted this hard requirement to 100-chars.
E.g. the lines, the CI is complaining about, could be split of course, but for the sake of readability I would rather keep them as their are right now.

The 80-char limit is for the sake of readability; A standard terminal window is 80 characters wide. I don't see a problem with breaking those lines; better than the wrapping at 80.

@bith3ad
Copy link
Author

bith3ad commented Nov 12, 2025

  • Fixed the 80-char style issues.

@sahilnxp
Copy link
Contributor

@bith3ad Can you please tell me how you tested writing of fuse and did you update the ocotp pta also for this ?


assert(g_base_addr);

timeout = timeout_init_us(20);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use macro in place of 20

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no macro in the below loop implementation. Can we keep it that way?

*
* @bank Fuse bank number
* @word Fuse word number
* @[in]val Fuses to burn
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Value to burn ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure if you like it more.

@jenswi-linaro
Copy link
Contributor

Please fix the style issues and use only C-style comments (no //).

@sahilnxp
Copy link
Contributor

@bith3ad Can you please tell me how you tested writing of fuse and did you update the ocotp pta also for this ?

@bith3ad Please check this.

@github-actions
Copy link

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

@github-actions github-actions bot added the Stale label Dec 21, 2025
@bith3ad
Copy link
Author

bith3ad commented Dec 22, 2025

@bith3ad Can you please tell me how you tested writing of fuse and did you update the ocotp pta also for this ?

@bith3ad Please check this.

We tested this via the mechanism proposed in #7597

@github-actions github-actions bot removed the Stale label Dec 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants