Hi all,
On 20-07-18 13:09, Michal Simek wrote:
On 20.7.2018 08:12, Luis Araneda wrote:
Hi Michal,
On Thu, Jul 19, 2018 at 3:28 AM Michal Simek <michal.si...@xilinx.com> wrote:
Please take a look at
https://lists.denx.de/pipermail/u-boot/2016-November/274068.html which
was the series which should replace all these boards setting in a
generic way. Unfortunately I don't know why it didn't go through.
Neither do I :) some of them where 'done' as far as I remember, but it
has been a while and I have somewhat forgotten about them a little. They
have been used in production since then however for us.
There are plans to work on our u-boot again in the next few months and
my intention was to pick up the ones that did not get merged.
The last version of that series [1] (v6, 28 patches) has the state
"Changes Requested" on patchwork, and it even has some TODOs. It's a
generic way of reading a MAC address from an EEPROM with helper
functions.
I'm not proposing something as generic and elaborated as that series,
but an improvement to what is used today.
I sent this series to move some legacy options to Kconfig.
Additionally, the Zybo Z7 has its MAC address stored on an SPI FLASH,
which will likely require a new Kconfig option (MAC_ADDR_IN_SPI_FLASH)
eventually. Something that [1] doesn't cover (from what I read).
No, I did not have SPI memory available at the time, and was sort of
waiting for the generic EEPROM framework to progress (that died).
Having said that, adding SPI eeprom would have been trivial.
It just occurred to me that what I'm really doing in the fourth patch
is reading the MAC address from a generic memory connected to I2C,
because it's a generic memory read operation (device address, memory
address, read operation). So I think the name of the Kconfigs could be
CONFIG_MAC_ADDR_IN_I2C_MEMORY instead of
CONFIG_MAC_ADDR_IN_I2C_EEPROM. It can even be more generic like
CONFIG_MAC_ADDR_IN_I2C. What do yo think?
Well I think the generic memory framework did make sense at the time,
and didn't compulab merge something like this at some point?
And then regarding DM i2c. Driver is in the driver for a while but for
i2c muxes support it requires all subbusses to be listed in DTS file
which is not what it is common in Linux dt binding. That's why some work
needs to be done in this area to convert all platforms.
Yes, I realize that I2C muxes are a pending issue, but that's why I
only migrated the boards that are not using I2C muxes. From my point
of view, it's less work to be done when porting
Anyway, I just wanted to improve the current state of the code, I
don't need these changes for what I'm doing. So if you like to wait
for [1] to be merged, it's fine with me and we can drop this series,
otherwise, please review it so I can make changes if necessary.
[1] https://lists.denx.de/pipermail/u-boot/2017-May/291401.html
I have no problem to move ZYNQ_GEM_EEPROM_ADDR to Kconfig without
changing the name.
Oliver: Any comment about your patch series?
What I just wrote above :)
And I would let Joe to handle that mac address reading.
That v6 series contains a lot of patches which have been acked. The
biggest problem was about sunxi which is something what can be ignored.
If Oliver doesn't want to send v7 then I would recommend you simply take
his v6 version and that patches which are required and just send them
again. I think it won't take so much time because a lot of things were
already done.
I don't mind starting to work on a v7; i think one of the issues I ran
into was turn around time which took quite a while. I may even have v7
locally actually! I'll see what can be done within the comming period;
but again, we are going to update/add more support to our u-boot so I
should be working on this again soon-ish.
Thanks,
Michal
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
