-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add REALTEK_RTL8195AM to mbed-os #3758
Conversation
targets/targets.json
Outdated
@@ -2640,4 +2640,22 @@ | |||
"inherits": ["SARA_NBIOT"], | |||
"extra_labels": ["ublox", "HI2110", "SARA_NBIOT"] | |||
} | |||
"RTL8195A": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The line above should have delimiter (,
), this I believe is causing CI failures.
Can you also fix line endings please, it seems they are broken in:
|
mbed detect fails:
dumping data mbedls is getting from the system |
Compile errors out as well:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please fix mbed compile
and mbed detect
issues.
Do I need special firmware to work with mbed? |
Issues with build:
I changed the access rights there (
|
That's fixed now. Next issue:
|
I manage to flash the board (no fail file on the mount), but the blinky doesn't work (LED marked as D4 and D5 keep blinking), blinky uses LED1 (PB_4 -> D5) I've tried to change the frequency to make sure, but no change. I've also tried to use external LED connected to A0 (PA_0) but it doesn't work either. My guess is that board quietly refuses to flash, so back to my original question about the firmware. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot of binaries: images, executables and libraries in the sources eg (for windows as it's easier to find):
find . -name "*.exe"
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/bedit.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/checksum.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/coan.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cut.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/decomment.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/fart.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/gawk.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/grep.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/head.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/iarchive.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/nm.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/objcopy.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/objdump.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/padding.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/pick.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/readelf.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/sed.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/sort.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/strip.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/tail.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/basename.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/bash.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/bedit.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cat.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/checksum.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/coan.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cut.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/decomment.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/du.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/fart.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/gawk.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/grep.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/head.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/iarchive.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/nm.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/objcopy.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/objdump.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/padding.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/pick.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/printf.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/readelf.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/sed.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/sh.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/sort.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/stat.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/strip.exe
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/tail.exe
find . -name "*.dll"
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cyggcc_s-1.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cyggmp-10.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygiconv-2.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygintl-8.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygmpfr-4.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygncursesw-10.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygpcre-1.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygreadline7.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygwin1.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/iar_utility/tools/cygz.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cyggcc_s-1.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cyggmp-10.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygiconv-2.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygintl-8.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygmpfr-4.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygncursesw-10.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygpcre-1.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygreadline7.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygwin1.dll
./TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc/tools/cygz.dll
I don't think they should be part of the mbed OS, most of the tools seem to be standard toolchain/system tools anyway. It also means that it takes a lot of space:
du -hs TARGET_Realtek
44M TARGET_Realtek
@sg- I'm assuming we don't want all the executables/libs (especially the standard ones) in the repo.
DA_0 = (PORT_U<<4|0), | ||
DA_1 = (PORT_U<<4|1), | ||
// Arduino connector namings | ||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you comment that out? The board is Arduino form factor and the pins one the board are described with this names so it'll be confusing for the users.
extern "C" { | ||
#endif | ||
|
||
#if 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An awful lot of code was commented out, is that work in progress or something that got forgotten?
targets/targets.json
Outdated
"progen": {"target": "rtl8195a"}, | ||
"progen_target": "rtl8195a", | ||
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SPI", "TRNG", "EMAC"], | ||
"default_build": "standard", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think default_build
is necessary -> @theotherjimmy ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely not needed.
targets/targets.json
Outdated
"progen_target": "rtl8195a", | ||
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SPI", "TRNG", "EMAC"], | ||
"default_build": "standard", | ||
"features": ["IPV4", "LWIP"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IPV4
feature is not used anywhere as far as i can tell (it's being defined as FEATURE_IPV4
and grepping the code for it doesn't have any results)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, there's not a good place to document it, but the IPV4 feature only exists for backwards compatibility. Adopting feature LWIP is sufficient.
|
||
ENTRY(Reset_Handler) | ||
|
||
INCLUDE "mbed-os/targets/TARGET_Realtek/TARGET_AMEBA/TARGET_RTL8195A/device/TOOLCHAIN_GCC_ARM/export-rom_v02.txt" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tools/targets.py
Outdated
"""RTL8195A Hooks""" | ||
@staticmethod | ||
def binary_hook(t_self, resources, elf, binf): | ||
sys.path.append(os.path.abspath("./mbed-os/targets/TARGET_Realtek/TARGET_AMEBA/sdk/soc/realtek/8195a/misc")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That cannot be hardcoded like that. Please look how other targets build the paths.
@@ -0,0 +1,102 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't accept files with headers like that. You'll need to change it, Apache 2.0 is standard for mbed OS. Please do that for all the files with proprietary header.
@@ -0,0 +1,748 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, @0xc0170 shouldn't this PR be submitted against master? |
Yes, good catch. @Archcady please rebase on top of master. |
@bulislaw This PR will also need to be submitted against master. We can either edit this one or this will need to be closed and reopened against master. |
Please just edit this one if possible, I don't want all the comments lost. |
Hi guys! When setting ARMCC compile options for makefiles, there are several options I initially imported from GCC which do not comply with the latest ARMCC compiler or are not recognized. The options passed are given below. Is there any guidance for me to update CFLAGS to fit ARMCC compiling environment? I don't know if old formats should be alternated or discarded... CFLAGS += --cpu=cortex-m3 -mthumb -g2 -w -Os -Wno-pointer-sign -fno-common -fmessage-length=0 -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-short-enums -DF_CPU=166000000L -std=gnu99 -fsigned-char Thanks and Regards |
I would hope you don't need to touch them, the default ones (https://github.com/ARMmbed/mbed-os/blob/master/tools/toolchains/arm.py) should do hopefully. |
@bulislaw The point is that I need to use ARMCC compiler to create some rtl8195a-specific library files before arm.py eventually works. This makefile is meant for those prerequisite libraries. |
@0xc0170 I remember you did some libraries building using mbed OS build system, is that straightforward? If not you can try using the same flags as mbed OS when building with ARMC (you can see the actual commands using |
You can use our tools to build a library (with some manual steps) or reproduce similar build profile manually via makefile. As I see it, you need to use your own profile as flags diverse from what we specify for mbed, explanation below. Back to the question about flags between toolchains,
Some of them are not in ARMCC neither IAR, they are GCC specific, you can compare what we have for GCC and ARMCC (we define many of those you specified for GCC ARM as well), you will find some flags similarities to the above (like ARMCC uses --c99 --gnu that might be similar to gnu99 but be aware might not 100 match in some cases, as some of those flags are specific toolchain extensions). I noticed you are using no-short-enums and signed char, that is not compatible with our flags (unsigned char, short enums for instance). Be aware of this, and care must be taken when mixing translation units (mbed and your library). |
I hope this is still related, but mbed CLI also supports building libraries and uses all the same flags as You could also always use the |
Thank you guys. It seems simple makefile could work with my case now. The only problem now is that as @0xc0170 mentioned above compiler enum is default short size while in rtl8195 it is defined as int size. This is defined in our rom code so if I use the lib built with ARMCC it shows enum packing incompatible errors. I wonder if there is any pre-configuration to force ARMCC compiler to define enum as int length when I build the library. Definitely our preference is not to change our rom code. Any suggestions on this? Thanks |
Seems like we have a problem in changing our code base, right now it says that we are PR against ARMmbed:master from Archcady:mbed-os-5.3 and I think it should be from Archcady:master. Do anyone have any method to fix that? Many thanks. |
I don't think it matters, just rebase your branch on top of mbed OS master. @Archcady @ian-qian-ting do you guys have special mbed firmware for RTL8195A that works with mbed? The one that comes with the board doesn't seem to be able to flash mbed binary and it doesn't report serial number so the board is not recognized by |
@bulislaw I changed the base to ARMmbed:master, and the pull request shows up with over 250+ commits that are differences between mbed-os-5.3 and master branch. Did I do this right? About the firmware, maybe the firmware on board is somehow corrupted. You could try update it with this one (FYI: plugin micro-usb cable to CON2 while pressing the button right next to it, then you could update firmware) |
(uvision, gcc_arm, iar)
should use space instead of tab
remove rtx and switch to rtx2
/morph test-nightly |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputBuild failed! |
Strange for these errors: |
@Archcady Can you look at those errors, I can see there also some C99 types redefinition errors (gcc arm). arm toolchain reports the error you shared above |
|
Seems that should have a default parameter as false for backwards compatibility? @hasnainvirk @kjbracey-arm |
As I see those functions |
We forgot that those functions were made "public" by the EMAC stuff - EMAC drivers have to call those mbed_lwip_ functions to register. (The fact there are no EMAC drivers in the main tree is why we missed it - none showed up on searches). Doesn't make any sense, of course, as the point of the EMAC is to abstract the stack - the last thing an EMAC driver should be doing is calling lwIP-specific registration. Those calls really should be viewed as internal. But I believe there's no alternative until #4079 is merged. I guess we should restore the old prototypes for bringup and bringdown for backwards EMAC compatibility. |
PR #4431 restores the original prototypes for these functions. |
@0xc0170 @sg- Hi Martin and Sam, Realtek folks are asking if there is anything that needs them to address on this lwip parameter? It seems this new parameter added in the function call nsapi_error_t mbed_lwip_bringdown is in the master branch whereas Realtek's PR is based off feature_cmsis5 branch. Thanks. |
As @kjbracey-arm highlighted, we got a fix in place. If I got an access to write to this PR, I would attach a fix to this PR, and run again tests, that should make it green ! |
The fix was merged, also cmsis5. This needs to be rebased to get those out and we shall be good ! |
@Archcady Can you rebase please? Or we might create a new PR rebased |
rebased here #4438 |
Description
Add REALTEK_RTL8195AM to mbed-os
Status
IN DEVELOPMENT
Greentea test
ARMCC:
mbedgt: test suite results: 51 OK
mbedgt: test case results: 178 OK
GCC:
mbedgt: test suite results: 51 OK
mbedgt: test case results: 178 OK
IAR:
mbedgt: test suite results: 51 OK
mbedgt: test case results: 178 OK
Todos