# Modifying and building u-boot **URL:** \ **Category:** NXP LX2160\ **Created:** [September 6, 2023, 8:04pm UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712 "2023-09-06T20:04:57Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 6, 2023, 8:04pm UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/1 "2023-09-06T20:04:57Z")
I must be missing something, but I don’t see a LX2160A-based board in Solidrun’s u-boot git repository. Are the instructions somewhere on how to build u-boot for Honeycomb? Background: We have noticed hangups in specific scenarios involving load-exclusive/store-exclusive instructions. These appear similar to issues observed on a different A72-based board, for which the solution is to set bit 31 in CPUACTLR\_EL1 (see [Documentation – Arm Developer](https://developer.arm.com/documentation/100095/0003/way1382037666700)). –Elad ---
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 7, 2023, 11:21am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/2 "2023-09-07T11:21:26Z")
Looks like I was mislead by the presence of a u-boot tree in SolidRun’s github repository. As far as I can tell the way to build u-boot for Honeycomb is to clone SolidRun/lx2160a\_build and build a full image, which seems a bit heavy. –Elad ---
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 7, 2023, 7:47pm UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/3 "2023-09-07T19:47:23Z")
I finally figured out how to change u-boot and update it on the SD card. Unfortunately, enabling snoop-delayed exclusive handling prevents u-boot from starting. I added the code in the same place as the other errata workarounds that update this register. Not sure what is going on. –Elad ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [September 8, 2023, 5:48am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/4 "2023-09-08T05:48:47Z")
The patch you need to unlock this is here, [fix(layerscape): unlock write access for SMMU SMMU\_CBn\_ACTLR · nxp-qoriq/atf@4414070 · GitHub](https://github.com/nxp-qoriq/atf/commit/4414070b4ffe3805df03ad22f5d88d7304ad6c79) We are working on rebasing the lx2160a\_build BSP to the latest version that will include it by default. ---
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 8, 2023, 9:40am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/5 "2023-09-08T09:40:56Z")
Thanks, Jon. The patch does not fix the hang, but now I understand that the problem is (likely) that CPUACTLR\_EL1 access is restricted to EL3. Perhaps I can update the ATF code to set that bit? –Elad ---
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 8, 2023, 10:09am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/6 "2023-09-08T10:09:06Z")
OK, got it to work by patching ATF. ```auto root@honeycomb:~/src$ ./cpuactlr 0x200 cpu=9 cpuactlr_el1=80000180000000 (80000000) root@honeycomb:~/src$ ./cpuactlr 0x1 cpu=0 cpuactlr_el1=80000180000000 (80000000) root@honeycomb:~/src$ ./cpuactlr 0x2 cpu=1 cpuactlr_el1=80000180000000 (80000000) ``` If this indeed fixes the hang problems then you may want to add this patch to the upstream BSP. –Elad ---
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 9, 2023, 8:59pm UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/7 "2023-09-09T20:59:10Z")
I ran a stress test for 24 hours on two Honeycomb boards (yes, we pretty much bought all of the Canadian stock…). The board that has bit 31 of CPUACTLR\_EL1 cleared (the default) froze multiple times and had to be rebooted after each freeze. The board that has bit 31 set with the modified firmware is alive and kicking. I think this is an issue with A72-based SoCs that should probably be reported to NXP and ARM. TI is already aware, as we have seen the same problem on one of their boards. –Elad ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [September 10, 2023, 4:21am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/8 "2023-09-10T04:21:54Z")
Both ARM and NXP are aware. The errata has to do with the prefetcher of the MMU. Thanks for testing. ---
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 10, 2023, 10:08am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/9 "2023-09-10T10:08:54Z")
Do you have a reference number for the erratum? The patch you posted above seems unrelated. ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [September 13, 2023, 4:45am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/10 "2023-09-13T04:45:27Z")
I apologize for the confusion. My patch is for another hang errata. Can you post a test case so I can test and reproduce the bug you are addressing? ---
**Author:** ![elahav](https://avatars.discourse-cdn.com/v4/letter/e/ecc23a/32.png) [@elahav](https://community.solid-run.com/u/elahav)\ **Post date:** [September 13, 2023, 9:48am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/11 "2023-09-13T09:48:34Z")
The test case won’t help you much unless you have access to QNX 7.1. The hang itself is in the kernel, and requires running in EL1. What we suspect is happening is that a core fails to acquire a spin lock, getting stuck in WFE forever: 1. Core A reads the value of a spin lock with `ldaxr` and observes that it is busy 2. Core A issues `wfe` 3. Core B releases the spin lock by writing 0 using `stlr` Step 3 should emit an event, per section B2.9.2 of the ARMv8 manual, as the global monitor transitions to an open state, but that doesn’t seem to happen in some cases. Replacing `wfe` with `yield` avoids the hang, as does adding an explicit `sev` after `stlr` for releasing the lock. Note that 99.9% of the time the system behaves just fine and it takes a kernel-heavy stress test on all cores running for about half an hour before the hang happens. When we saw a similar issue on another board it turned out that the hardware provider has their own cache coherency implementation and not the ARM CCI. I don’t know if that is the case here. –Elad ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [September 13, 2023, 10:10am UTC](https://community.solid-run.com/t/modifying-and-building-u-boot/712/12 "2023-09-13T10:10:06Z")
Thanks for the update. The LX2160a uses ARM’s CCN-508 CHI implementation for coherency. I doubt there are any modifications. There is an errata regarding entering and exiting wfi/wfe and atomic operations. I will review that again and look at NXP’s assembly to verify it meets their recommend workaround.