[PATCH 4/5] ARM: novena: Read Ethernet MAC address from EEPROM
Sascha Hauer
sha at pengutronix.de
Wed Jan 25 07:42:58 PST 2023
On Thu, Jan 26, 2023 at 12:31:04AM +1100, John Watts wrote:
> On Wed, Jan 25, 2023 at 09:19:23AM +0100, Sascha Hauer wrote:
> > Yes, normally it should be set up already, unless of course there is
> > some needed pinctrl configuration in an unrelated device tree node.
> >
> > Sascha
>
> Hi Sascha,
>
> Here's what I think is going on:
>
> - The I2C line requires 3v3_DELAYED for pull-ups
> - The EEPROM requires 3v3_DELAYED for power
> - 3v3_DELAYED requires VGEN5 from the PMIC (acts as a gate)
> - The PMIC is loaded after the EEPROM
>
> Most things on the board require these delayed rails, so I'm wondering
> what the approach should be here. Should I:
>
> - Rewrite the device tree to reference these delayed rails
> - Probe the PMIC first
The barebox PFUZE PMIC driver is not a real regulator driver it's just a
no-op driver providing a regmap, so by definition it is not guilty.
My wild guess is that regulator-audio-codec needs to be enabled to let
the EEPROM work. The Audio codec sits on the same I2C bus as the EEPROM
and it could be that the codec just pulls the I2C data line low when
it's not powered up.
You could verify this by doing a
gpio_direction_output 156 0
on the command line and then try to read from the EEPROM. It sould fail
and start working again after a
gpio_direction_output 156 1
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the barebox
mailing list