Skip to content
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

Basic rboot #332

Closed
flexiti opened this issue Oct 10, 2015 · 41 comments
Closed

Basic rboot #332

flexiti opened this issue Oct 10, 2015 · 41 comments

Comments

@flexiti
Copy link
Contributor

flexiti commented Oct 10, 2015

I compile a Basic_rBoot example and I have such a thing.
Any advice?

13:22:38 **** Build of configuration Sming for project Basic_rBoot ****
make rebuild
OC out/build/libmain2.a
make -C /c/tools/sming/Sming/rboot
make[1]: Entering directory /c/tools/sming/Sming/rboot' CC rboot-stage2a.c LD /c/tools/sming/Basic_rBoot/out/build/rboot-stage2a.elf FW /c/tools/sming/Basic_rBoot/out/build/rboot-hex2a.h CC rboot.c LD /c/tools/sming/Basic_rBoot/out/build/rboot.elf FW /c/tools/sming/Basic_rBoot/out/firmware/rboot.bin make[1]: Leaving directory/c/tools/sming/Sming/rboot'
C+ app/application.cpp
CC /c/tools/sming/Sming/rboot/appcode/rboot-api.c
In file included from c:/tools/sming/Sming/rboot/appcode/rboot-api.c:17:0:
c:/tools/sming/Sming/rboot/appcode/rboot-api.c: In function 'rboot_set_config':
c:/Espressif/ESP8266_SDK/include/mem.h:8:21: error: implicit declaration of function 'pvPortMalloc' [-Werror=implicit-function-declaration]
#define os_malloc pvPortMalloc
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:44:19: note: in expansion of macro 'os_malloc'
buffer = (uint8_)os_malloc(SECTOR_SIZE);
^
c:/Espressif/ESP8266_SDK/include/mem.h:9:21: error: implicit declaration of function 'vPortFree' [-Werror=implicit-function-declaration]
#define os_free vPortFree
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:63:2: note: in expansion of macro 'os_free'
os_free(buffer);
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c: In function 'rboot_write_flash':
c:/Espressif/ESP8266_SDK/include/mem.h:10:21: error: implicit declaration of function 'pvPortZalloc' [-Werror=implicit-function-declaration]
#define os_zalloc pvPortZalloc
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:106:20: note: in expansion of macro 'os_zalloc'
buffer = (uint8 *)os_zalloc(len + status->extra_count);
^
In file included from c:/tools/sming/Sming/rboot/appcode/rboot-api.c:18:0:
c:/Espressif/ESP8266_SDK/include/osapi.h:16:19: error: implicit declaration of function 'ets_memcpy' [-Werror=implicit-function-declaration]
#define os_memcpy ets_memcpy
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:113:2: note: in expansion of macro 'os_memcpy'
os_memcpy(buffer, status->extra_bytes, status->extra_count);
^
cc1.exe: all warnings being treated as errors
make: *_* [out/build//c/tools/sming/Sming/rboot/appcode/rboot-api.o] Error 1

13:22:39 Build Finished (took 1s.398ms)

@raburton
Copy link
Member

What's your environment, compiler version, etc.?

@flexiti
Copy link
Contributor Author

flexiti commented Oct 10, 2015

  1. Sming/develop
  2. CHERTS Version 2.0.8 of 01.09.2015
  3. Windows 7
    and as he suggests:

"-. To download the Windows (145Mb) and install my Unofficial Development Kit for Espressif ESP8266.
-. Download and install the Java Runtime x86 (jre-7uXX-windows-i586.exe)
-. Download and install Eclipse Mars x86 to develop in C ++ (eclipse-cpp-mars-R-win32.zip). Unpack the archive to the root of drive C.
-. Download and install MinGW. Run mingw-get-setup.exe, the installation process to select without GUI, ie uncheck "... also install support for the graphical user interface".(after that I have: gcc (GCC) 3.4.4 (msys special)
-. Download the (84Mb) my scripts to automate the installation of additional modules for MinGW.
"

btw. other samples (few checked randomly) are compiled ok

@raburton
Copy link
Member

I don't use windows for development, but no one else has noticed this. What version of the sdk are you using?

@flexiti
Copy link
Contributor Author

flexiti commented Oct 10, 2015

1.3

@raburton
Copy link
Member

Hmm, that's very odd then! I have tested with 1.3 & 1.4 on Linux and it doesn't complain. Possibly it's an issue of a newer version of gcc that's got different default warnings enabled. I'll have a look.

@hreintke
Copy link
Contributor

@flexiti : @raburton
I think it is the udk 208 which is the problem.
It compiles ok on udk 206, switch to 208 -> fails, switch back to 206 -> OK
No idea (yet) what change in that causes the error.

@flexiti
Copy link
Contributor Author

flexiti commented Oct 10, 2015

@raburton @hreintke
I have added
#include system/include/esp_systemapi.h
in rboot-api.c

and and compilation looks good, I do not know if that works now - I tested further

@flexiti
Copy link
Contributor Author

flexiti commented Oct 10, 2015

now it looks quite well, if it works'll see tomorrow.


17:07:02 **** Build of configuration Sming for project Basic_rBoot ****
make rebuild
OC out/build/libmain2.a
make -C /C/tools/sming/Sming/rboot
make[1]: Entering directory /C/tools/sming/Sming/rboot' CC rboot-stage2a.c LD /c/tools/sming/Basic_rBoot/out/build/rboot-stage2a.elf FW /c/tools/sming/Basic_rBoot/out/build/rboot-hex2a.h CC rboot.c LD /c/tools/sming/Basic_rBoot/out/build/rboot.elf FW /c/tools/sming/Basic_rBoot/out/firmware/rboot.bin make[1]: Leaving directory/C/tools/sming/Sming/rboot'
C+ app/application.cpp
CC /C/tools/sming/Sming/rboot/appcode/rboot-api.c
CC /C/tools/sming/Sming/rboot/appcode/rboot-bigflash.c
AR out/build/app_app.a
LD out/build/app_0.out
E2 out/firmware/rom0.bin
Checking for spiffs files
files directory exists. Creating out/firmware/spiff_rom.bin
Creating rom spiff_rom.bin of size 65536 bytes
Adding files in directory files
testfile.txt added to spiffs (40 bytes)

17:07:06 Build Finished (took 4s.200ms)

@AutomationD
Copy link
Contributor

...We need more testing in standardized environments to confirm that it works, and then eliminate user-specifc issues. While on vacation I'm building a build matrix for linux/windows/mac

@raburton
Copy link
Member

This is a tricky one. The include file you have added isn't a standard sdk include, so adding it to the rBoot code in Sming would then be Sming specific. We want to try to avoid having to alter external components that we bundle to make updating them easier. It's also worth noting that the definition for some of these undefined functions does change, e.g. pvPortZalloc has changed between sdk 1.3 and 1.4, so third part include files that define them aren't the best way to go unless they are kept up to date and full of conditional sections. The proper answer to this is that Espressif should include these in the header files of the sdk, and update them if they change the functions. While they refuse to do that my preference would be to ignore implicit function declarations, it really doesn't do any harm as the code won't link if the actual functions can't be found, you just get the error message at the linker step instead of the compile step.

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

Has anyone successfully compile it on CHERTS 2.8 or 2.9? (SDK 1.3 and SDK 1.4)?

@raburton
With new CHERTS Version 2.0.9 (SDK 1.4) problem is almost the same.
(if RBOOT_ENABLED ?= 0 all is ok)
What is your suggestion ?
In my opinion, if it is coupled to Sming should work well here and less interest to me whether it is transferable outside sming - it could be Sming specific.
(So far all examples and Sming are build correctly in this CHERTS environment).


09:26:38 **** Build of configuration Sming for project Basic_rBoot ****
make rebuild
CLEAN
OC out/build/libmain2.a
make -C /C/tools/sming/Sming/rboot
make[1]: Entering directory /C/tools/sming/Sming/rboot' CC rboot-stage2a.c LD /c/tools/sming/Basic_rBoot/out/build/rboot-stage2a.elf FW /c/tools/sming/Basic_rBoot/out/build/rboot-hex2a.h CC rboot.c LD /c/tools/sming/Basic_rBoot/out/build/rboot.elf FW /c/tools/sming/Basic_rBoot/out/firmware/rboot.bin make[1]: Leaving directory/C/tools/sming/Sming/rboot'
C+ app/application.cpp
CC /C/tools/sming/Sming/rboot/appcode/rboot-api.c
In file included from c:/tools/sming/Sming/rboot/appcode/rboot-api.c:17:0:
c:/tools/sming/Sming/rboot/appcode/rboot-api.c: In function 'rboot_set_config':
c:/Espressif/ESP8266_SDK/include/mem.h:6:27: error: implicit declaration of function 'pvPortMalloc' [-Werror=implicit-function-declaration]
#define os_malloc(s) pvPortMalloc(s, "", 0)
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:45:19: note: in expansion of macro 'os_malloc'
buffer = (uint8_)os_malloc(SECTOR_SIZE);
^
c:/Espressif/ESP8266_SDK/include/mem.h:5:27: error: implicit declaration of function 'vPortFree' [-Werror=implicit-function-declaration]
#define os_free(s) vPortFree(s, "", 0)
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:64:2: note: in expansion of macro 'os_free'
os_free(buffer);
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c: In function 'rboot_write_flash':
c:/Espressif/ESP8266_SDK/include/mem.h:9:27: error: implicit declaration of function 'pvPortZalloc' [-Werror=implicit-function-declaration]
#define os_zalloc(s) pvPortZalloc(s, "", 0)
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:107:20: note: in expansion of macro 'os_zalloc'
buffer = (uint8 *)os_zalloc(len + status->extra_count);
^
In file included from c:/tools/sming/Sming/rboot/appcode/rboot-api.c:18:0:
c:/Espressif/ESP8266_SDK/include/osapi.h:16:19: error: implicit declaration of function 'ets_memcpy' [-Werror=implicit-function-declaration]
#define os_memcpy ets_memcpy
^
c:/tools/sming/Sming/rboot/appcode/rboot-api.c:114:2: note: in expansion of macro 'os_memcpy'
os_memcpy(buffer, status->extra_bytes, status->extra_count);
^
cc1.exe: all warnings being treated as errors
make: *_* [out/build//C/tools/sming/Sming/rboot/appcode/rboot-api.o] Error 1

09:26:39 Build Finished (took 1s.436ms)

@raburton
Copy link
Member

What is your suggestion ?

I have already given my thoughts on the subject. We should not be making modifications to 3rd party components that are included in Sming because it makes them harder to maintain. There are several options here, we specify supported environments so people use something that works (the current version of Sming targets sdk 1.3 and is largely untested with 1.4 so you shouldn't really be using that anyway). Or we can easily add the compile flag to ignore these harmless warnings. The best solution would be for Espressif to fix their headers. In the mean time there are easy work-arounds for people who want to use them (add a header file or add the compiler flag yourself).

@hreintke
Copy link
Contributor

I agree with Richard that we should not modify 3rd party components (unless absolutely necessary to get Sming working)
On the supported environments : We already started to include notes on versions/dependencies of other components. That is in my opinion the way to forwarding to include support for newer versions of that.
In case of SDK, we explicitly mentioned V1.3.0.
If we want to support SDK V1.4.0 or UDK 2.0.x (or any other upgrade to dependent sofware, we should agree to that, create an issue to gather issues & solutions (including backward compatibility and documentation), PR those to develop branch to be included in the next Sming Release

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

Okay, I'll wait with the rboot unless there are patch no matter where

@raburton
Copy link
Member

Okay, I'll wait with the rboot unless there are patch no matter where

You could very easily use one of the work-arounds while you wait for a fix in a future release.

@hreintke
Copy link
Contributor

@raburton :
I see you have some Sming specific lines in your rboot-api.c
What if you make that generic and in your code just include a "framework specific" include.

Something like :
#include "rboot_framework_config"
Each framework which wants to implement rboot then creates that file locally.

For sming that then would be f.e.

// prevent include..
#define __USER_CONFIG_H__
#include system/include/esp_systemapi.h
....
....

That would leave rboot external platform independent an allow sming to configure

@raburton
Copy link
Member

Something like that could work, I'll look into the idea.

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

@raburton @hreintke
To tell the truth I do not need a rboot now , I am doing just tests, for you, for us.
I think we should do a "user frendly" program without interfering with other sources.
Now I test SDK 1.4 with Sming, because I am looking for why errors occur -8 in TCP transmission and if that the new version would change anything.

In the SDK version 1.4 this "patch" in rboot-api.c that I made earlier stopped working, so for now I leave rboot because I want to see the impact the new version of the SDK for the error -8.
I return to the subject maybe tomorrow again and I see what you @raburton suggest :)

@kireevco
Btw. sming wiki:
Manual Windows instalation (DEPRECATED!) is easy, why is deprecated ?

In QuicInstal I'm stuck on:
Open an administrative cmd.exe command prompt and paste the text from the box below and press enter:
@PowerShell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Why "by force" you want to make Linux from Windows? Windows users do not like the "secret" scripts. If they would have liked, they would work on Linux :))

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

I wrote here about Windows Installer, because I wanted to check that the installation method QuickInstall have identical effects at compile time (I personally installed it manually)

@alonewolfx2
Copy link
Member

@flexiti i like GUI things but i both using linux and windows. also i will create basic gui for windows users :) (i installed lastest sming manually on my win10 machine)
@raburton @hreintke 's idea is good. i think you can do it.

@raburton
Copy link
Member

@flexiti the reason it's stopped working at 1.4 is because the definition of those functions in the sdk has changed. The extra include file that comes with Sming (which could be included in rBoot, via one method or another) has not (yet?) been updated with the new v1.4 definitions. Not an ideal solution. This is why the best fix would be for Espressif to produce proper header files that define the functions in their libraries.

The other workaround (compiler flag to ignore warnings about implicit functions definitions) should still work.

@AutomationD
Copy link
Contributor

@flexiti

Manual Windows instalation (DEPRECATED!) is easy, why is deprecated ?
Because it's almost close to impossible to control user's environment with manual install. With choco you can control environment.

@flexiti

In QuicInstal I'm stuck on:
Open an administrative cmd.exe command prompt and paste the text from the box below and press enter:
@PowerShell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

What is your problem?

Why "by force" you want to make Linux from Windows? Windows users do not like the "secret" scripts. If they would have liked, they would work on Linux :))

There is no secret, chocolatey is partnered with Microsoft and officially supported by Windows 10. The benefit of chocolatey is that it allows dependency-management without building a crazy zip file with all dependencies in it. I will just say, right now it is the best way for package distribution.

I understand Windows users. And there are 2 other solutions: zip file and some sort of installer. I am inclined towards installer. Built using something like tkiniter and compiled via py2exe. It has to be be cross-platform too.

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

@kireevco
the "secret" was in quotes, If you look at the details you do not see the idea.
The idea is to be avoided wherever possible so that you have to learn something about the "X" because You want to install and use the "A"

What is may problem:
Performing according to what is written just got the information that the command is not recognized (Win7)

@AutomationD
Copy link
Contributor

Performing according to what is written just got the information that the command is not recognized (Win7)

@flexiti log/screnshot?

@hreintke
Copy link
Contributor

In my opinion, when installing sming, we should not "force" windows/linux/mac users to a specific toolset.
And we should not duplicate installation processes/documentation from other projects which we then have to maintain. And maybe the user is already using (part of) the toolset needed for sming. We cannot force someone to install exactly as sming team sees appropriate.

Working likje that we "only" have to define

  • "external dependencies"
    which software is needed to compile/flash Sming/Examples
    what version(s) and/or specific options are needed
  • How to install the latest/develop sming framework
  • What needs additionally to be configured to have sming using the "external dependencies.

@AutomationD
Copy link
Contributor

In my opinion, when installing sming, we should not "force" windows/linux/mac users to a specific toolset.
And we should not duplicate installation processes/documentation from other projects which we then have to maintain. And maybe the user is already using (part of) the toolset needed for sming.

How do you make sure user doesn't have something incompatible in the environment? for example esp sdk of a wrong version? Or make.exe from a different version? etc... This have been an issue less than a year ago before we standardized toolset. Everything has to be standardized and tested. With too much of choice everything will break eventually. Look at Arduino.

We cannot force someone to install exactly as sming team sees appropriate.

Why not?

Chocolatey is good because it pulls down binaries from their sources, for example Eclipse.

"external dependencies" which software is needed to compile/flash Sming/Examples what version(s) and/or specific options are needed
How the latest/develop sming framework
What needs additionally to be configured to have sming using the "external dependencies.

Sorry, but this is year 2000. For today's folks this is way to complicated, trust me. We had a discussion with @anakod, and we had a roadmap towards simplification for new users. Let's revisit this question when he comes back.

@hreintke
Copy link
Contributor

How do you make sure user doesn't have something incompatible in the environment? for example esp sdk of a wrong version? Or make.exe from a different version? etc... This have been an issue less than a year ago before we standardized toolset. Everything has to be standardized and tested. With too much of choice everything will break eventually. Look at Arduino.

Because we define correctly what is needed for environment esp version, sdk version, make.exe type/version when necessary. We do not need a lot of choice.
We can decide on every dependency what we support -> issues will only be solved for suported dependencies.

We cannot force someone to install exactly as sming team sees appropriate.

Why not?

Because this is the year 2015 where we are not the only framework which is around.
When forcing installation to a sming way a user can create a lot of trouble when just installing sming to experiment for the first time. Just as an example so don't comment on the details.
By forcing windows users to set mingw\sys\1.0\bin and mingw\bin absolutely at the front of the path, a windows user with other frameworks installed might get into trouble.
We should say : we need make version x.y.z to be able to build sming.

Chocolatey is good because it pulls down binaries from their sources, for example Eclipse.

As @flexiti mentioned above,
The idea is to be avoided wherever possible so that you have to learn something about the "X" because You want to install and use the "A"

Sorry, but this is year 2000. For today's folks this is way to complicated, trust me.

Sming users are c++ developers, not an accidental user for whom installs something should be a one ckick experience

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

@kireevco
image

@AutomationD
Copy link
Contributor

Because we define correctly what is needed for environment esp version, sdk version, make.exe type/version when necessary. We do not need a lot of choice.
We can decide on every dependency what we support -> issues will only be solved for suported dependencies.

Sorry, I disagree, everything needs to be packages for an easy use. User shouldn't decide and resolve dependencies.

Sming users are c++ developers, not an accidental user for whom installs something should be a one ckick experience

This is still year 2000. Today you must think about developer as a user, look at modern open-source projects: "If a user has an issue - that's a bug".

By forcing windows users to set mingw\sys\1.0\bin and mingw\bin absolutely at the front of the path, a windows user with other frameworks installed might get into trouble.

You are right. That's why it needs to be packaged properly

We should say : we need make version x.y.z to be able to build sming.

Not an option. It will kill my interest, If I were a new person to try sming. I want something working right a way, otherwise I will simply choose Arduino platform or AdiuinoESP ide.

Again, it has to be packaged to some sort of one-click action (exctact zip, install netbeans/eclipse plugin, or something else). mingw and toolset has to be built-in (as it is in Arduino IDE) and not dependant on environment. On the other hand we need to be mindfull about including/distributing third-party binaries.

@AutomationD
Copy link
Contributor

@flexiti are you sure you have powershell installed?:)

@hreintke
Copy link
Contributor

Final remark from me on this today.

How are we going to maintain this "one click" environment for windows/linux/mac ??

@AutomationD
Copy link
Contributor

@hreintke I don't see any issues, what is the problem?

As I mentioned, interface will look very similar (using qt, tkiniter or something similar), although it will pull platform-specific binaries + sming code from release source.

@raburton
Copy link
Member

You only need it for windows, maybe for mac, you certainly don't need it for linux. Setting up the environment on linux for a linux user is trivial.

@AutomationD
Copy link
Contributor

@raburton well, Linux will work with less effort, because we will be already building binaries. We might do rpm/deb repo or something. I'm still exploring the solution that will work best for all environments.

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

@kireevco
"@flexiti are you sure you have powershell installed?:)"

QuickStart ....Where is that information that I have to install it? :)
Quick Install is not so quick ? ;)

@AutomationD
Copy link
Contributor

@flexiti Usually It is a part of an updated Windows.

Quick Install is not so quick ? ;)

What troll school did you graduate from? :)

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

@kireevco

Usually It is a part of an updated Windows.

Maybe...usually, Maybe installation can succeed

I do not want to comment because you have not heard of finished programming environments that do not force you to learn Windows, Linux, Mac. The more, so that the resulting code is not intended for any of these environments but on ARM?
I'm just trying to show that our goal is to Sming and ESP8266 ... rather than spending a lot of time on the environment. Environment should be installed virtually seamlessly. I see that we absolutely do not understand each other.

Programming Windows:
instead of adapting to any existing environment (eg. CHERTS) we will create our own ... it's a little uphill

I understand that I have no further testing because all is well - I have to educate :)

@AutomationD
Copy link
Contributor

Sorry, I don't think I understand your point, @flexiti . Until it is more specific, and beyond complaining I don't think there is anything to chat about. As soon as I get something ready I'll post it and we'll chat then.

@raburton
Copy link
Member

See PR #338 against develop. Improved integration and hopefully a fix for @flexiti's problem with 1.3. It won't help 1.4, that needs an update to the esp_systemapi.h header.

@flexiti
Copy link
Contributor Author

flexiti commented Oct 13, 2015

@raburton Cool, tomorrow check on :)

@flexiti
Copy link
Contributor Author

flexiti commented Oct 14, 2015

@raburton
Checked, Its ok ,
Now you only need to compile, nothing needs to be modified and an example compiles in the environment 2.0.8 UDK - it should be :))

Question about rom0.ld file

  • it should be added to a new project in which you want to use rboot?
    If so, it's quite little described

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants