Just as was done with BBB, I've set up a bug tracker for X15 at:
http://bugs.elinux.org/projects/beagleboard-x15
Thanks
Bill
Thanks!
Perhaps Matthijs can input a sufficient description of the “Ethernet reset” issue he reported on the list.
I would like to see it duplicated on the board he has and then let us duplicate it here as well…
Gerald
I don't have a board. Since I don't have a "project description" better
than "peek, poke, tinker" it didn't feel appropriate to reply to Jason's
announcement of the initial batch of boards.
The schematics however leave no doubt that the PHYs will get reset on warm
reset, and I have a lot of experience with the ethernet switch on our
dm814x-based board. (Unfortunately that project got shelved, but my
internet connection actually still runs via one as workaround for the
ethernet autonegotiation problem my laptop has with my adsl router.)
I can still submit it to the bug tracker if you want.
I also have a growing list of minor stuff that probably only affects the
schematic and not the actual board (mislabeled pins and such). I was
planning to email those in a single batch, do you want those via the bug
tracker as well?
If you do not like the names, send your suggestions to me and i will decide whether or not to change them. DO not put those in the bug tracker as they are not issue.
Gerald
One more note, in the current design there is no warm reset. Only a full reset. This is to cover up for a bug in the processor. When ES2.0 silicon is made available, that should be fixed.
Gerald
OK, Gerard, sorry to be blunt but can you go back to my posts and actually
*read* them this time instead of obliquely glancing at them before hitting
reply? Which is apparently what you did, since...
One more note, in the current design there is no warm reset. Only a full
reset. This is to cover up for a bug in the processor.
I explained more than once that the change I was suggesting was needed
purely because of this.
When ES2.0 silicon is made available, that should be fixed.
I explicitly asked about this, since if the erratum is fixed and the
workaround-hardware is removed, PORz (and thereby ENET_PORZ) becomes a true
power-on-reset again and my change is no longer needed. I only got a reply
from Jason who didn't know whether 2.0 would fix the reset erratum.
Sorry. My apologies. I am very busy and have a lot going here at my company. So I do the best I can with my free time.
I will work harder in the future to meet your expectations.
Again, I am very sorry.
Gerald
I can understand you're busy. Many of us are. But it's not like I wrote
novel-length emails to plow through, and having to repeat myself wastes my
time, yours, and that of anyone else following this topic.
Any idea how far away 2.0 is? Since if it's sufficiently soonish then it
may not be worthwhile to include my change.
[...]
Any idea how far away 2.0 is? Since if it's sufficiently soonish then it
may not be worthwhile to include my change.
Silicon?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/id.c?id=81032e34e184a8d63598d215a6d4a3352018ffea
just to give a hint.
ES2.0 x15 -> cannot comment :).
Ask Jason on ES2.0 time frame. He is the TI guy.
Your change is already on the list for ES2.0.
Gerald
OK, so the next x15 production run after the current one (the first
opportunity to include my ethernet reset change) will hopefully have 2.0
silicon...
I'll still post to the bug tracker, but rephrase it to request that the
PHYs are only reset at true power-on, regardless of whether this is
accomplished by removing the reset-workarounds (if 2.0 has arrived) or
including my proposed change to the ethernet reset (if we're still stuck at
1.1).
Good to hear also that the ethernet and MMC speed issues have been
addressed in 2.0!
I don’t expect ES2.0 before the end of December. But, that can change. By then we hope to have shipped around 6,000 boards to distributors. However, we may have to shift those out based on silicon availability from TI. Right now we have 2500 parts that we can get to from what our distributor is telling us,
If Jason and the team can confirm that this change causes no issues with SW, we could cut it in sooner, but only after Jason signs off on this change. Depending on when all that happens, how much is in WIP and where we are at that time with the build schedule, will determine when we can actually cut the change in.
Gerald
I also just noticed the pull-up value as drawn in the schematic is 10 times
the value suggested by the PHY datasheet, and even that one causes a
worryingly high RC-time and might start to race against software
initialization...
You know what, forget it, I withdraw my proposal. When 2.0 is out the issue
can be fixed properly, and until that time the eth1 speed limitation makes
it a mediocre switch anyway...
Yes there are other issues in the switch as well from a silicon standpoint. It works fine on both of the X15 ports and per TI it should not be working on one of them. So, consider that a freebie I guess that ours does work.
Supposedly it is fixed in the infamous ES2.0 version of the silicon. But I have no visibility in what is going on there at TI.
Gerald