≡
[10:27:22] <plaes> jo0nas: mainline u-boot needs to read board revision from eeprom
[10:30:26] <plaes> btw.. is this compatible with Lime2 - https://www.olimex.com/Products/Modules/Time/MOD-RTC2/open-source-hardware ?
[11:08:57] <jo0nas> plaes: I agree that _if_ different delays are truly needed to apply to _gmac_ then indeed u-boot needs to know how to distinguish, which is done most specifically by reading revision from eeprom - similar to how the Olimex fork has dones it - but my point above is that there is no need for varying delays if instead applying the delay at the PHY driver
[11:10:09] <jo0nas> ...so if you are telling me what mainline u-boot "needs" to do to follow the same path as Olimex has followed, then yes - but there might be other better paths
[11:11:07] <jo0nas> plaes: if you are telling me that the board cannot possibly have its GMII delays handled at the PHY then please elaborate - I am certainly no expert on it
[11:17:02] <plaes> neither am I, but there's currently a lot of discussion happening in the linux-sunxi mailinglist about this
[11:17:39] <plaes> and there's actually another issue regarding lime2 ethernet - it's still depending on the legacy clocks
[11:18:57] <plaes> https://lore.kernel.org/linux-arm-kernel/20200430115702.5768-1-plaes@plaes.org/
[11:28:42] <jo0nas> interesting! I don't follow that list - does that discussion touch possible switch in device-tree from gmii to gmii-id?
[11:31:24] <plaes> gmii -> gmii-id is currently happening, but I don't know whether someone has pushed patch for Lime2
[11:35:28] <jo0nas> as I understand it, when that happens there should be no need to tie delays to board revision, as then delays are tied to the PHY which (again in my vague understanding) means the device-tree file for LIME2 should be able to state one set of delays for the Realtek PHY and another set for the Micrel PHY
[11:36:04] <diego71> plaes: I take a look this morning on the linux-sunxi mailing list but I didn't see any patch for olimex board
[11:36:11] <plaes> yeah, no patches for lime2 yet
[11:37:08] <plaes> ACTION starts designing rtc shield for lime2..
[11:55:01] <diego71> quite interesting
[16:39:10] <Tsvetan> plaes MOD-RTC2 is clock which can be connected to any I2C, LIME2-SHIELD + MOD-RTC2 work fine with LIME2
[17:37:46] <Tsvetan> plaes have you used SD NAND
[17:38:14] <Tsvetan> I got samples, this is SD-card in solderable package, eliminates the SD-card connector
[17:38:51] <Tsvetan> industrial grade -40+85C
[17:39:30] <Tsvetan> and the best one is that the speed is 25MB/s both for read and write
[17:40:38] <Tsvetan> 6x8x0.8 mm LGA-8 pin package
IRC #olimex 2020-10-26
[10:09:58] <leon-anavi> hi[10:27:22] <plaes> jo0nas: mainline u-boot needs to read board revision from eeprom
[10:30:26] <plaes> btw.. is this compatible with Lime2 - https://www.olimex.com/Products/Modules/Time/MOD-RTC2/open-source-hardware ?
[11:08:57] <jo0nas> plaes: I agree that _if_ different delays are truly needed to apply to _gmac_ then indeed u-boot needs to know how to distinguish, which is done most specifically by reading revision from eeprom - similar to how the Olimex fork has dones it - but my point above is that there is no need for varying delays if instead applying the delay at the PHY driver
[11:10:09] <jo0nas> ...so if you are telling me what mainline u-boot "needs" to do to follow the same path as Olimex has followed, then yes - but there might be other better paths
[11:11:07] <jo0nas> plaes: if you are telling me that the board cannot possibly have its GMII delays handled at the PHY then please elaborate - I am certainly no expert on it
[11:17:02] <plaes> neither am I, but there's currently a lot of discussion happening in the linux-sunxi mailinglist about this
[11:17:39] <plaes> and there's actually another issue regarding lime2 ethernet - it's still depending on the legacy clocks
[11:18:57] <plaes> https://lore.kernel.org/linux-arm-kernel/20200430115702.5768-1-plaes@plaes.org/
[11:28:42] <jo0nas> interesting! I don't follow that list - does that discussion touch possible switch in device-tree from gmii to gmii-id?
[11:31:24] <plaes> gmii -> gmii-id is currently happening, but I don't know whether someone has pushed patch for Lime2
[11:35:28] <jo0nas> as I understand it, when that happens there should be no need to tie delays to board revision, as then delays are tied to the PHY which (again in my vague understanding) means the device-tree file for LIME2 should be able to state one set of delays for the Realtek PHY and another set for the Micrel PHY
[11:36:04] <diego71> plaes: I take a look this morning on the linux-sunxi mailing list but I didn't see any patch for olimex board
[11:36:11] <plaes> yeah, no patches for lime2 yet
[11:37:08] <plaes> ACTION starts designing rtc shield for lime2..
[11:55:01] <diego71> quite interesting
[16:39:10] <Tsvetan> plaes MOD-RTC2 is clock which can be connected to any I2C, LIME2-SHIELD + MOD-RTC2 work fine with LIME2
[17:37:46] <Tsvetan> plaes have you used SD NAND
[17:38:14] <Tsvetan> I got samples, this is SD-card in solderable package, eliminates the SD-card connector
[17:38:51] <Tsvetan> industrial grade -40+85C
[17:39:30] <Tsvetan> and the best one is that the speed is 25MB/s both for read and write
[17:40:38] <Tsvetan> 6x8x0.8 mm LGA-8 pin package
