Feature emac merge test (again) #6837
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Initial work by Bartek Szatkowski in ARMmbed#4079, reworked following review of ARMmbed#5202 to transform the entire system into C++, retaining the basic functionality. Bartek's summary: * Porting ethernet to EMAC * Updating EMAC to enable multiple interfaces * Untangling networking classes, making the abstractions a bit clearer to follow, etc * General refactoring * Removal of DEVICE_EMAC flag and introducing DEVICE_ETH and DEVICE_WIFI Revisions since initial branch: * Remove lwip depencies * Correct doxygen warnings * Remove emac_api.h, replace with C++ EMAC abstract class. * Create OnboardNetworkInterface, and LWIP implementation. * Mappings since ARMmbed#4079 lwip-interface/nsapi_stack_lwip.c -> LWIPStack.cpp lwip-interface/ipstack_lwip.c -> LWIPInterface.cpp netsocket/mbed_ipstack.h -> OnboardNetworkStack.h hal/emac_api.h -> EMAC.h * Reinstate use of EthInterface abstraction * Correct and clarify HW address EMAC ops * Restore MBED_MAC_ADDR implementation * Integrate PPP support with LWIP::Interface. * Convert K64F lwIP driver to K64F_EMAC. To do: * Convert emac_stack_mem.h to follow this pattern. * Figure out DEVICE_ETH/EMAC * Update all drivers to use EMAC
Rather than let "EthernetInterface" be the base EMAC NetworkInterface,
insert an "EMACInterface" class.
EthernetInterface then derives from EMACInterface and EthInterface.
A Wi-Fi driver can derive from EMACInterface and WiFiInterface - this
will be more logical than deriving from EthernetInterface and
WiFiInterface.
This does mean adding a couple of virtual inheritances to avoid
duplicate NetworkInterfaces:
NetworkInterface
/ \
virtual / \ virtual
/ \
EMACInterface WiFiInterface
\ /
\ /
\ /
MyCustomWiFiInterface
This has been superceded by CellularBase. Name change occurred late in review of ARMmbed#4119 and original unused CellularInterface was left behind.
As we've introduced virtual inheritance to support EMACInterface, we can no longer use C-style casts or static_cast to downcast from NetworkInterface to more specific types. RTTI is disabled in the toolchains, so dynamic_cast is unavailables. Add virtual downcast methods to permit conversions to the 6 derived classes. Probably only needed for EMACInterface, WiFiInterface and EthInterface, but handles the set.
Make ETHERNET configuration the default if DEVICE_EMAC is present, instead of if FEATURE_LWIP is present. This limits it to targets which have been ported to the new EMAC API. Add LWIP feature to JSON config, as in principle the targets shouldn't be adding it themselves. Opens scope to having Nanostack-based tests. Disable tests for the Realtek and Wifi drivers that aren't ported yet.
I would like to restrict these to devices with "device_has": "EMAC", but the framework doesn't currently permit that. Revisit as more drivers are EMAC-enabled or if the framework changes.
Pending Nanostack EMAC work, disable the border router.
Suppress Odin W2 and Realtek Wi-fi drivers using .mbedignore
Pending EMAC driver update, these tests won't compile.
instead of old memory interface.
Nanostack doesn't set the link status callback. Make sure the two example drivers don't crash if it isn't set.
Make Nanostack an OnboardNetworkInterface, implementing add_ethernet_interface so it can use EMAC drivers. Can now be used via EthernetInterface, and be the system's default network stack. Legacy support for NanostackEthernetInterface retained. Some restructuring of mesh interface code to fit into the OnboardNetworkStack:::Interface system.
Removed flagging of the new/old code.
Checking DEVICE_EMAC is problematic - particularly for the Odin W2 where apps have been shutting this off to disable the Wi-fi interface. Make drivers check a locally-relevant flag instead, pending new thoughts on how to achieve application/test-relevant flagging for XXX:get_default_instance() being provided by a system. However that is achieved, drivers do require a flag set purely by the target - they mustn't be tripped up by an add-on module providing itself as the system's default EMAC.
Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
This is required to setup the MPU for ENET bus master accesses Signed-off-by: Mahesh Mahadevan <[email protected]>
Do not disable SYSMPU, instead add access for ENET bus master Signed-off-by: Mahesh Mahadevan <[email protected]>
This driver is used by more SoC's than K64F Signed-off-by: Mahesh Mahadevan <[email protected]>
This is a dummy test merge - operation was actually performed as a rebase, and will be pushed as such. This contains the same final tree contents as my current proposed rebase, and hopefully gitk will show a semi-legible diff for the bits touched in the merge commit.
kjbracey
force-pushed
the
feature-emac-merge-test
branch
from
beeb2c6 to
edaba68
Compare
|
/morph build |
Build : SUCCESSBuild number : 1943 Triggering tests/morph test |
Test : SUCCESSBuild number : 1765 |
Exporter Build : SUCCESSBuild number : 1593 |
Possibly, but it's not related to this branch. This is a test merge of master into feature-emac. There aren't any FEATURE_COMMON_PAL references in anything modified on feature-emac. I think all you're seeing are still lingering in master. @SeppoTakalo - maybe a little follow-up from #6577? |
|
Tests passed - feature-emac now rebased to this tree. Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Same procedure as #6635. Simpler rebase this time.
This is a dummy test merge - operation was actually performed as a rebase, and will be pushed as such. This contains the same final tree contents as my current proposed rebase, and hopefully
gitkwill show a semi-legible diff for the bits touched in the merge commit.Actual rebased feature-emac is at https://github.com/kjbracey-arm/mbed-os/commits/feature-emac - when this passes CI, I will force push that to feature-emac.
Pull request type
[ ] Fix
[X] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change