Overlay confusion

With the help of you all, I have a successfully working BME280 (Temp/H/P) sensor as well as well working extermal clock (DS3231)
I have been researching on how to utilize the D18B20 temp sensor (which I use several of on several different RPi’s) and followed instructions https://elinux.org/EBC\_Exercise\_31\_Dallas\_1-Wire
BTW, I use a BBB, latest Debian XFCE image.
I followed (as well as everything else in the instructional post):

Now edit /boot/uEnv.txt and find the line:
#uboot_overlay_addr4=/lib/firmware/<file0>.dtbo
and change it to
uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo

I assume that the P9.12 means pin12 on P9

After reboot, the D18b20 worked great! Got a Temp reading several times tried over.
Problem, now my ext clock and BME280 did not work anymore.
So, I commented out the line ’ uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo ’
rebooted, and clock and BME280 worked again, but not the DS18B20

So, as I mentioned in a previous thread, I obviously do not know what I am doing when it comes to overlays for sure.
My question then, as it is now, is it because the overlay_addr4 is the same in both my i2c and this W1-P912
If yes, how do I determine which addr to use? Any addr which is commented out in uEnv.tx? Which in my case could be addr0, addr1, addr2, addr3, addr5
Or,
is it something else?

u-boot will scan for eeprom and use these 4 variables:

uboot_overlay_addr0=<file0>.dtbo
uboot_overlay_addr1=<file1>.dtbo
uboot_overlay_addr2=<file2>.dtbo
uboot_overlay_addr3=<file3>.dtbo

Another 4 are available for end users to just use as they feel like it:

uboot_overlay_addr4=<file4>.dtbo
uboot_overlay_addr5=<file5>.dtbo
uboot_overlay_addr6=<file6>.dtbo
uboot_overlay_addr7=<file7>.dtbo

Each is loaded in order from 0 → 7…

If you don’t have any capes with an eeprom, feel free to use any from 0 → 7…

Regards,

Great - TY for quick response.
Just to clarify my question: I should NOT use the same addr in the overlay assignments. in other words, using addr in both overlays cancels out the former in uEnv.txt, yes?

uEnv.txt is just a variable assignment that get’s loaded into memory by u-boot…

So the last variable definition gets used…

Regards,

sorry for being dense, but your answer then is ‘yes’, if addr4 is used twice it would cancel one out?

Correct last define would be set

TY Again!