Firstly, thanks for the response, and I completely agree with your point that the u-boot is the minimal initial code that load and execute the kernel, but then I believe even the bootlader can support accessing peripherals of the system. and I could see from the u-boot terminal that it list all other devices either through Pincontrol subsystem or through individual driver model. but I wonder why only the I2C is missing. also, my concern is if I load the same kernel which is properly probing the I2C bus, if loaded and executed straight away by the "start.elf" which is not probing the I2C bus if loaded through u-boot.
Thank you so much for pointer let me try with Alexander Graf's repo probably "RPI_Stable", and try to explore I2C, even I need to start with LED from u-Boot using Pinctrl, that's propriety next to the I2C access. sure I will give you an update on led as soon as work on it.epoch1970 wrote: ↑Tue Oct 23, 2018 12:58 pmIIRC the DT passed by the pi bootloader is used as is, unless you actively replace it with your own (with the "dt" commands available in u-boot)
I tend to believe the issue might be in u-boot's code instead.
I would try with one of the repos owned by Alexander Graf, https://github.com/agraf/u-boot/
He is the current u-boot maintainer for the RPI platform, his tree gets merged upstream but I've had denx releases fail where agraf's would work.
Personally I am using agraf's "rpi-stable" branch and have no experience with i2c.
There is an "rpi-next" branch that is more recent, but the current effort seems to be around 64-bit u-boot with EFI support.
PS: I you have any practical experience to share about LED control on Pi 3 within u-boot, I'd be keen on a few hints
Providing the i2c relevant part would be very helpful
Instead of your interpretation the actual settings would be more helpful for diagnostics.