search

espressif / ESP8266_NONOS_SDK

ESP8266 nonOS SDK
Other
923 stars 535 forks source link

Upgrading to nonos SDK 3.10 #212

Open scargill opened 5 years ago

scargill commented 5 years ago

I've not upgraded since NONOS SDK 2.1 due to not enough IRAM in later versions. I use RBOOT by Richard Burton - virtually all my functions are in Flash - my code works perfectly in SDK 2.1 - . I've not kept up with the need to define a partition table. Does the latest version (today - 21/02/2019) free up more space and do the docs now simply explain partition table information?

fvpalha commented 5 years ago

I'm using RBOOT, too. I am using NON SDK 2.2.x commit 34f1abd (12/27/2018). I'm still not sure on upgrading to the NONOS SDK 3.1.0

The project esp_nano_httpd_fota can be an alternative to RBOOT.

marcelstoer commented 5 years ago

I haven't seen a v3.1 in the wild yet. Pointer?

scargill commented 5 years ago

Github- it’s there and updated today.

From: Marcel Stör [mailto:notifications@github.com] Sent: 21 February 2019 15:58 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Author author@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

I haven't seen a v3.1 in the wild yet. Pointer?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-466054218 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgzYgqG00n3n8PLz-pGL-1CaHJqxqks5vPsIVgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUg_W8gdnl6j0WZa_0CcYmK86Legx6ks5vPsIVgaJpZM4bHaSu.gif

marcelstoer commented 5 years ago

Never mind, I thought you were referring to an official release. Seems you just mean the latest commit on master - which was first labeled as v3.1 on Jan 2nd.

scargill commented 5 years ago

I don’t know the difference, I assumed if it’s on GIT it is official.

From: Marcel Stör [mailto:notifications@github.com] Sent: 21 February 2019 16:20 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Author author@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

Never mind, I thought you were referring to an official release. Seems you just mean the latest commit on master - which was first labeled as v3.1 on Jan 2nd.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-466063071 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUg3u1SpvwfcVFVNLMap9EMV3beryPks5vPsdDgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUgz8FsD29HC2cZPFBrGNT9DFczf0oks5vPsdDgaJpZM4bHaSu.gif

davydnorris commented 5 years ago

I've been using latest since it came out - for me moving to the partition table model was only a minor hassle in terms of updating my code and my Makefile, but there are several things I have noticed that are quite cool:

Truth be told, these things were explicit before, but they were all defined solely in my makefile, and I had separate definitions for the various flash sizes I had to deal with. It's now laid out in my code, and automatically calculated from a single flash size define passed in during the build. I use additional macro directives in the code to output information about where to flash the various items, but these are also in my makefile

My code is now pretty much independent of the makefile settings

scargill commented 5 years ago

That’s nice, Davy but in all this time I still have little clue how the make file works, never mind partition tables. What I have works all the way up to SDK 2.1 – I’m not a Linux programmer so some of that remains beyond me. I don’t know where to start changing the make file.

From: davydnorris [mailto:notifications@github.com] Sent: 21 February 2019 22:34 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Author author@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

I've been using latest since it came out - for me moving to the partition table model was only a minor hassle in terms of updating my code and my Makefile, but there are several things I have noticed that are quite cool:

Truth be told, these things were explicit before, but they were all defined solely in my makefile, and I had separate definitions for the various flash sizes I had to deal with. It's now laid out in my code, and automatically calculated from a single flash size define passed in during the build. I use additional macro directives in the code to output information about where to flash the various items, but these are also in my makefile

My code is now pretty much independent of the makefile settings

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-466195291 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgyUnjw1I8k6HaTO9NWgpGV0ky5xTks5vPx7mgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUg4PvA8-jiSTToIWJBwyk3ayfiqJ2ks5vPx7mgaJpZM4bHaSu.gif

someburner commented 5 years ago

While I think it's important to actually understand the partition table, which is really very simple- it's just a short list mapping addresses to various sectors of flash needed by the SDK- I can see it being a little confusing if you don't already have these locations defined in your project.

For a 4MB ESP8266 (eg ESP-12E) and rBoot with 512KB roms, all you have to do is, in user_main.c, make it look like this:

#define SDK_RF_CAL_ADDR 0x3FB000
#define SDK_PHY_DATA_ADDR 0x3FC000
#define SDK_PARAM_ADDR 0x3FD000
#define SPI_FLASH_SIZE_MAP  FLASH_SIZE_32M_MAP_512_512 // 4
#define SDK_PRIV_PARAM_ADDR 0x7C000
#define SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM SYSTEM_PARTITION_CUSTOMER_BEGIN

static const partition_item_t p_table[] = {
    { SYSTEM_PARTITION_BOOTLOADER,          0x0,                 0x1000 },
    { SYSTEM_PARTITION_RF_CAL,              SDK_RF_CAL_ADDR,     0x1000 },
    { SYSTEM_PARTITION_PHY_DATA,            SDK_PHY_DATA_ADDR,   0x1000 },
    { SYSTEM_PARTITION_SYSTEM_PARAMETER,    SDK_PARAM_ADDR,      0x3000 },
    { SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM, SDK_PRIV_PARAM_ADDR, 0x1000 },
};

void user_pre_init(void)
{
    if(!system_partition_table_regist(p_table, sizeof(p_table)/sizeof(p_table[0]), SPI_FLASH_SIZE_MAP)) {
        os_printf("system_partition_table_regist fail\r\n");
        while(1);
    }
}
davydnorris commented 5 years ago

Actually @someburner, there are a few things you would need to change:

and you also need to include the actual code partitions in this list, which for an OTA enabled 4MB 512k system would start at 0x002000 an 0x082000 (0x2000 higher than the base OTA due to rBoot), and would be 512k in size, minus 2k for rBoot and minus whatever size needed for your system or your own parameters, whichever is larger. In this case let's assume the system parameters are largest size at 1+1+3=5k, so our max OTA partition size is 0x80000 - 0x002000 - 0x005000 = 0x079000

#define SYSTEM_PARTITION_OTA_SIZE      0x79000

{ SYSTEM_PARTITION_OTA_1,              0x002000,     SYSTEM_PARTITION_OTA_SIZE },
{ SYSTEM_PARTITION_OTA_2,              0x082000,     SYSTEM_PARTITION_OTA_SIZE },
someburner commented 5 years ago

@davydnorris

Good catch re: rBoot size. Although technically the rboot binary only takes a single sector, the 2nd sector stores configuration.

Regarding SYSTEM_PARTITION_OTA_N parameters, it was my understanding that is only required if using the Espressif OTA method, which I'm not even sure works for rBoot? The configuration I posted boots and OTAs using rBoot-style OTA. It would be nice to know what's going on under the hood and how much these things matter.

davydnorris commented 5 years ago

I think you may be right there regarding the rBoot OTA approach. I don't know if there's any way you can specify that info for rBoot (I seem to remember seeing something similar though).

I've found having the explicit OTA partition size has saved me once already when I accidentally set up an OTA flash built for a 1M partition for a set of devices that were configured as 512k

scargill commented 5 years ago

Ok, now take it easy with me…. can I use that as below- assuming again 4MB ESP8266 and my code is somewhat OVER 512k…

From: Jeff Hufford [mailto:notifications@github.com] Sent: 22 February 2019 00:20 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Author author@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

While I think it's important to actually understand the partition table, which is really very simple- it's just a short list mapping addresses to various sectors of flash needed by the SDK- I can see it being a little confusing if you don't already have these locations defined in your project.

For a 4MB ESP8266 (eg ESP-12E) and rBoot with 512KB roms, all you have to do is, in user_main.c, make it look like this:

define SDK_RF_CAL_ADDR 0x3FB000

define SDK_PHY_DATA_ADDR 0x3FC000

define SDK_PARAM_ADDR 0x3FD000

define SPI_FLASH_SIZE_MAP FLASH_SIZE_32M_MAP_512_512 // 4

define SDK_PRIV_PARAM_ADDR 0x7C000

define SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM SYSTEM_PARTITION_CUSTOMER_BEGIN

static const partition_item_t p_table[] = { { SYSTEM_PARTITION_BOOTLOADER, 0x0, 0x1000 }, { SYSTEM_PARTITION_RF_CAL, SDK_RF_CAL_ADDR, 0x1000 }, { SYSTEM_PARTITION_PHY_DATA, SDK_PHY_DATA_ADDR, 0x1000 }, { SYSTEM_PARTITION_SYSTEM_PARAMETER, SDK_PARAM_ADDR, 0x3000 }, { SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM, SDK_PRIV_PARAM_ADDR, 0x1000 }, };

void user_pre_init(void) { if(!system_partition_table_regist(p_table, sizeof(p_table)/sizeof(p_table[0]), SPI_FLASH_SIZE_MAP)) { os_printf("system_partition_table_regist fail\r\n"); while(1); } }

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-466222843 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgzGQcnSVCXnlB2o_CxXilRWB_8Qaks5vPzfJgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUg3xfqIs1cpEZxKtmB_xQjuOcNRTIks5vPzfJgaJpZM4bHaSu.gif

scargill commented 5 years ago

Which is the correct version - assuming 4MB ESP12 and roms that are in between 512k and 1 meg each... I think I'm up to 700k.??? Your feedback, guys, is MOST appreciated... so that's it? a change to user_main.c?

I can feel success is almost within my grasp...

someburner commented 5 years ago

If you look in the SDK's include/user_interface.h you can find the flash_size_map enum that you need to look at to choose for the #define SPI_FLASH_SIZE_MAP definition. So if you have roms > 512KB, you will need to use the 1MB size, which would be FLASH_SIZE_32M_MAP_1024_1024, so the definition would be:

#define SPI_FLASH_SIZE_MAP FLASH_SIZE_32M_MAP_1024_1024

and you'd also want to change the SDK_PRIV_PARAM_ADDR so the SDK param sector is at the end of the 1MB, so SDK_PRIV_PARAM_ADDR would become (I think):

#define SDK_PRIV_PARAM_ADDR 0xFC000
scargill commented 5 years ago

NICE - but I had a feeling it would not be THAT simple - so - I added the code above, adjusted for 1 meg roms - and upgraded to the SDK here in GIT. NOPE.

In SDK 2.1 I get build/app_0.out: file format elf32-xtensa-le

Sections: Idx Name Size VMA LMA File off Algn 0 .data 00000d38 3ffe8000 3ffe8000 000000e0 24 CONTENTS, ALLOC, LOAD, DATA 1 .rodata 00002ea8 3ffe8d40 3ffe8d40 00000e20 24 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .bss 0000b2e0 3ffebbe8 3ffebbe8 00003cc8 24 ALLOC 3 .text 00007774 40100000 40100000 00003cc8 22 CONTENTS, ALLOC, LOAD, READONLY, CODE 4 .irom0.text 0009d284 40202010 40202010 0000b440 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE

As you can see above compilation works in 2.1 and I still have .text room to go.

Using the new SDK 3.1 - with the additional info as advised above, I get all the way to the end of the compilation then the dreaded error -

c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: build/app_0.out section .text' will not fit in regioniram1_0_seg' collect2.exe: error: ld returned 1 exit status mingw32-make.exe: *** [build/app_0.out] Error 1

Just as I've had with previous attempts to upgrade the SDK. Ideas, anyone???

scargill commented 5 years ago

One more change to the above - I changed the bootloader size to 0x2000 as davydnorris pointed out... made no difference - same ".text will nor fit into region iram1_0_seg" error.

davydnorris commented 5 years ago

I am happy to take a look at your project @scargill and see if I can get it to fit?

scargill commented 5 years ago

Here it is: https://bitbucket.org/scargill/esp-go/src/master/ - this one is up to date -- works with SDK 2.1 - the new info in user_main.c is commented out as it prevents compiling for 2.1 - the main make file is in the outer directory - simply called MAKEFILE - th emain file which calls others is /user/petes_code.c

The project is written in C, not using Arduino.... and originally emanated from an MQTT demo and now conrtols a range of peripherals by serial of MQTT.

I'm in the process of adding more fonts.

Pete

davydnorris commented 5 years ago

OK I've pulled the code and had a bit of a go - had to fiddle a lot with the Makefile, and pull down esptool2 and make that as well, and play with your python script to make Python 3.7 like it, and then I started building...

By default I turn on all warnings and there's a lot to fix - lots of implicit function declarations, which can make the code not optimise very well, and a bunch of other dodgy assignments to and from int32 and pointers. I'll have a bit more of a play but it's taken a chunk of my time already.

scargill commented 5 years ago

Thank you so much for your efforts… sorry about esptool2. I use Python 2.7 – never thought about someone not having that.

The idea here is not to worry too much about making my code more efficient – but finding out why it fits into sdk 2.1 and nor 3.1 – Espressif are supposed to have done some optimisations, putting more of their library in FLASH. If I end up with less, not more room then there is no point in upgrading the SDK – I was hoping to get past the IRAM issue and get more space for expansion.

Regards

Pete

From: davydnorris [mailto:notifications@github.com] Sent: 24 February 2019 14:22 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

OK I've pulled the code and had a bit of a go - had to fiddle a lot with the Makefile, and pull down esptool2 and make that as well, and play with your python script to make Python 3.7 like it, and then I started building...

By default I turn on all warnings and there's a lot to fix - lots of implicit function declarations, which can make the code not optimise very well, and a bunch of other dodgy assignments to and from int32 and pointers. I'll have a bit more of a play but it's taken a chunk of my time already.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-466781481 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgzEOiLiO6FvJ2WcDucdV6PrPxeyAks5vQqAFgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUg5aJZJ2D7s3NblA0z5zYlzHBvyydks5vQqAFgaJpZM4bHaSu.gif

davydnorris commented 5 years ago

I had to change it just to get it to compile - trying not to change anything at all if I can help it. One thing I am doing is pulling the espmissingincludes.h header as they have fixed all that up now. But the rest is just missing headers and definitions.

I also have to get used to rBoot and its link map too

fvpalha commented 5 years ago

Hi. Someone have a simple example with rboot in SKD 3.1.0 ?

scargill commented 5 years ago

Even with new partition data and pre init I've still not managed a successful compile higher than sdk 2.1

On 28 February 2019 14:01:17 Fernando Vilmar Palha notifications@github.com wrote:

Hi. Someone have a simple example with rboot in SKD 3.1.0 ?— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

fvpalha commented 5 years ago

I compiled in SDK 3.1.0 after add the code:

#include "user_interface.h"

#define SDK_RF_CAL_ADDR 0x3FB000
#define SDK_PHY_DATA_ADDR 0x3FC000
#define SDK_PARAM_ADDR 0x3FD000
#define SPI_FLASH_SIZE_MAP  FLASH_SIZE_32M_MAP_512_512 // 4
#define SDK_PRIV_PARAM_ADDR 0x7C000
#define SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM SYSTEM_PARTITION_CUSTOMER_BEGIN

static const partition_item_t p_table[] = {
    { SYSTEM_PARTITION_BOOTLOADER,          0x0,                 0x1000 },
    { SYSTEM_PARTITION_RF_CAL,              SDK_RF_CAL_ADDR,     0x1000 },
    { SYSTEM_PARTITION_PHY_DATA,            SDK_PHY_DATA_ADDR,   0x1000 },
    { SYSTEM_PARTITION_SYSTEM_PARAMETER,    SDK_PARAM_ADDR,      0x3000 },
    { SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM, SDK_PRIV_PARAM_ADDR, 0x1000 },
};

void user_pre_init(void)
{
    if(!system_partition_table_regist(p_table, sizeof(p_table)/sizeof(p_table[0]), SPI_FLASH_SIZE_MAP)) {
        os_printf("system_partition_table_regist fail\r\n");
        while(1);
    }
}

But my code does not run after burn the ESP8266.

scargill commented 5 years ago

Doesn’t work??? Not a lot of point in copying that, then? Mine is slightly different anyway as my code sdoesn’t fit in 521k, I’m up to about 800k…

If you get it to work, please do let me know.

From: Fernando Vilmar Palha [mailto:notifications@github.com] Sent: 28 February 2019 16:52 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

I compiled in SDK 3.1.0 after add the code:

include "user_interface.h"

define SDK_RF_CAL_ADDR 0x3FB000

define SDK_PHY_DATA_ADDR 0x3FC000

define SDK_PARAM_ADDR 0x3FD000

define SPI_FLASH_SIZE_MAP FLASH_SIZE_32M_MAP_512_512 // 4

define SDK_PRIV_PARAM_ADDR 0x7C000

define SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM SYSTEM_PARTITION_CUSTOMER_BEGIN

static const partition_item_t p_table[] = { { SYSTEM_PARTITION_BOOTLOADER, 0x0, 0x1000 }, { SYSTEM_PARTITION_RF_CAL, SDK_RF_CAL_ADDR, 0x1000 }, { SYSTEM_PARTITION_PHY_DATA, SDK_PHY_DATA_ADDR, 0x1000 }, { SYSTEM_PARTITION_SYSTEM_PARAMETER, SDK_PARAM_ADDR, 0x3000 }, { SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM, SDK_PRIV_PARAM_ADDR, 0x1000 }, };

void user_pre_init(void) { if(!system_partition_table_regist(p_table, sizeof(p_table)/sizeof(p_table[0]), SPI_FLASH_SIZE_MAP)) { os_printf("system_partition_table_regist fail\r\n"); while(1); } }

But my code does not run after burn the ESP8266.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-468348496 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgyqxeC4eUG1nwq3fYnylmId2PiHWks5vSAlJgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUgxs3rQVEItMcvci4m985dEJKLWXJks5vSAlJgaJpZM4bHaSu.gif

fvpalha commented 5 years ago

@davydnorris and @someburner , can you share the Makefile and the main file of the project than works with rBoot in SDK 3.1.0 ?

I do not understand why the rom does not run.

Thank you.

eriksl commented 5 years ago

The latest (not officially released) commits from the SDK (master/HEAD) free up a LOT of IRAM. Definitely worth a try.

If you're using rboot, I don't think it's wise to mark it's flash regions as "well-known" SDK partition, like OTA_1 and OTA_2 etc. The SDK code will make assumptions about it, which may not hold. RBOOT is not the same as the SDK OTA mechanism.

This is my partition table (for use with either rboot or without), as an example for use with rboot:

static const partition_item_t partition_items[] =
{
    {   SYSTEM_PARTITION_RF_CAL,                RFCAL_OFFSET,               RFCAL_SIZE,             },
    {   SYSTEM_PARTITION_PHY_DATA,              PHYDATA_OFFSET,             PHYDATA_SIZE,           },
    {   SYSTEM_PARTITION_SYSTEM_PARAMETER,      SYSTEM_CONFIG_OFFSET,       SYSTEM_CONFIG_SIZE,     },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 0,    USER_CONFIG_OFFSET,         USER_CONFIG_SIZE,       },
#if IMAGE_OTA == 0
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 1,    OFFSET_IRAM_PLAIN,          SIZE_IRAM_PLAIN,        },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 2,    OFFSET_IROM_PLAIN,          SIZE_IROM_PLAIN,        },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 3,    SEQUENCER_FLASH_OFFSET,     SEQUENCER_FLASH_SIZE,   },
#else
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 1,    OFFSET_OTA_BOOT,            SIZE_OTA_BOOT,          },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 2,    OFFSET_OTA_RBOOT_CFG,       SIZE_OTA_RBOOT_CFG,     },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 3,    OFFSET_OTA_IMG_0,           SIZE_OTA_IMG,           },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 4,    OFFSET_OTA_IMG_1,           SIZE_OTA_IMG,           },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 5,    SEQUENCER_FLASH_OFFSET_0,   SEQUENCER_FLASH_SIZE,   },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 6,    SEQUENCER_FLASH_OFFSET_1,   SEQUENCER_FLASH_SIZE,   },
#endif
};

The actual values are supplied from the Makefile using -D...

scargill commented 5 years ago

Eriksl - you have me confused - up to now I've ben working on the asumption that this was required and nothing else. Clealry below is not QUITE right as it won't compile - the usual "won't fit IRAM" message.

but now you've introduced something called partition_items[] - care to elaborate for non-Linux tpyes like me?

#define SDK_RF_CAL_ADDR 0x3FB000
#define SDK_PHY_DATA_ADDR 0x3FC000
#define SDK_PARAM_ADDR 0x3FD000
#define SPI_FLASH_SIZE_MAP FLASH_SIZE_32M_MAP_1024_1024
#define SDK_PRIV_PARAM_ADDR 0xFC000
#define SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM SYSTEM_PARTITION_CUSTOMER_BEGIN

static const partition_item_t p_table[] = {
{ SYSTEM_PARTITION_BOOTLOADER, 0x0, 0x2000 },
{ SYSTEM_PARTITION_RF_CAL, SDK_RF_CAL_ADDR, 0x1000 },
{ SYSTEM_PARTITION_PHY_DATA, SDK_PHY_DATA_ADDR, 0x1000 },
{ SYSTEM_PARTITION_SYSTEM_PARAMETER, SDK_PARAM_ADDR, 0x3000 },
{ SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM, SDK_PRIV_PARAM_ADDR, 0x1000 },
};

void user_pre_init(void)
{
if(!system_partition_table_regist(p_table, sizeof(p_table)/sizeof(p_table[0]), SPI_FLASH_SIZE_MAP)) {
os_printf("system_partition_table_regist fail\r\n");
while(1);
}
}
kriegste commented 5 years ago

That's the name of the array!? In your example it is called p_table.

BTW, have you tried ditching rboot completely?

scargill commented 5 years ago

I would not know whwre to start ditching RBOOT and the learing curve would detract from what I’m actually making with all of this. RBOOT has worked perfectly for a long time.

So do I take it you can call the array anything…. Indicating that pre-init is the only place that refers to it by name?

From: kriegste [mailto:notifications@github.com] Sent: 03 March 2019 20:11 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

That's the name of the array!? In your example it is called p_table.

BTW, have you tried ditching rboot completely?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-469059184 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgyCIvPpCy0iOJoKBw4K2TUx6z6NAks5vTCxpgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUg5hnj5EMK5i0OJFhF0fd3bMXeIjhks5vTCxpgaJpZM4bHaSu.gif

scargill commented 5 years ago

No I understand – and your table is like the one I picked (an example further up) but mine has less in it – and still won’t compile in 3.1 (the whole point of this). A reminder that my code compiles and works every time in SDK 2.1 – any idea what changes are needed to make it work?

Pete

From: kriegste [mailto:notifications@github.com] Sent: 03 March 2019 20:11 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

That's the name of the array!? In your example it is called p_table.

BTW, have you tried ditching rboot completely?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-469059184 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgyCIvPpCy0iOJoKBw4K2TUx6z6NAks5vTCxpgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUg5hnj5EMK5i0OJFhF0fd3bMXeIjhks5vTCxpgaJpZM4bHaSu.gif

davydnorris commented 5 years ago

still looking at it @scargill - just got my own delivery on right now

fvpalha commented 5 years ago

Hi @eriksl

I am trying follow your suggestions, but yet do not work. The project compile, but the firmware (ROM) does not run in ESP8266.

I created a simple project to make a functional example using rBoot with NONOS SDK 3.1.0.

test_rBoot_NonOS_SDK3.1.0

Please @raburton, @davydnorris, @someburner, @scargill and someone who has an interest in the solution.

Thanks.

The latest (not officially released) commits from the SDK (master/HEAD) free up a LOT of IRAM. Definitely worth a try.

If you're using rboot, I don't think it's wise to mark it's flash regions as "well-known" SDK partition, like OTA_1 and OTA_2 etc. The SDK code will make assumptions about it, which may not hold. RBOOT is not the same as the SDK OTA mechanism.

This is my partition table (for use with either rboot or without), as an example for use with rboot:

static const partition_item_t partition_items[] =
{
  {   SYSTEM_PARTITION_RF_CAL,                RFCAL_OFFSET,               RFCAL_SIZE,             },
  {   SYSTEM_PARTITION_PHY_DATA,              PHYDATA_OFFSET,             PHYDATA_SIZE,           },
  {   SYSTEM_PARTITION_SYSTEM_PARAMETER,      SYSTEM_CONFIG_OFFSET,       SYSTEM_CONFIG_SIZE,     },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 0,    USER_CONFIG_OFFSET,         USER_CONFIG_SIZE,       },
#if IMAGE_OTA == 0
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 1,    OFFSET_IRAM_PLAIN,          SIZE_IRAM_PLAIN,        },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 2,    OFFSET_IROM_PLAIN,          SIZE_IROM_PLAIN,        },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 3,    SEQUENCER_FLASH_OFFSET,     SEQUENCER_FLASH_SIZE,   },
#else
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 1,    OFFSET_OTA_BOOT,            SIZE_OTA_BOOT,          },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 2,    OFFSET_OTA_RBOOT_CFG,       SIZE_OTA_RBOOT_CFG,     },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 3,    OFFSET_OTA_IMG_0,           SIZE_OTA_IMG,           },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 4,    OFFSET_OTA_IMG_1,           SIZE_OTA_IMG,           },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 5,    SEQUENCER_FLASH_OFFSET_0,   SEQUENCER_FLASH_SIZE,   },
  {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 6,    SEQUENCER_FLASH_OFFSET_1,   SEQUENCER_FLASH_SIZE,   },
#endif
};

The actual values are supplied from the Makefile using -D...

davydnorris commented 5 years ago

Hi @fvpalha - I don't actually use rBoot, I've just been using 3.1 for ages.

I had a look at your test project, and to be honest it's a bit of a mess. From what I can tell, you have dumped the rBoot source, the driver source supplied by Espressif, and a bunch of other stuff all into one directory. It's impossible to tell why your project isn't working - you need to make it really easy for us to help you!

Set up some subdirectories with the various standard pieces in, and then set up your user directory with your simple sample so that we know what file to look at

scargill commented 5 years ago

DavyNorris - as I have similar issues, you're more than welcome to take a look at my code - which is NOT all in one folder ....https://bitbucket.org/scargill/esp-go/src/master/

There are lots of files inc support for a range of peripherals - the main MAKEFILE (I've never used the linux makefile) is in the outer directory - and the "main page" is in user/petescode.c - the /user/user_main.c page is set up for sdk 2.1 and earlier - from what I've seen in here, my commented out partition table and pre_init function are not a lillion miles out - but I cannot get compilation in 3.1 or anything past 2.1 ---- the code works perfectly in 2.1 - masically mqtt and serial communications (there's a web interface but I set everyting up (2 ssids, id and an mqtt broker) in serial usually.

Pete

davydnorris commented 5 years ago

@scargill I am looking at yours but have my own code drop that's running a week late. As soon as I get that sorted I'll have a play.

As mentioned before, I tried to compile yours and got a ton of warnings. One of the things I've found is that undeclared functions can affect compiler optimisations, and you have a lot of those because your makefile suppressed the warnings.

Oh and your problem is different - you just have a lot of bloody code lol!

scargill commented 5 years ago

I wasn’t aware you were supposed to declare them and I’ve no idea how to turn warnings on and off, though I prefer the relevant silence of not having them on.. an example of that at the many scripts out there some of which I incorporate into “the script”. There are LOTS of warnings about which I can do nothing, I wish I could turn them off.

If you give me one concrete example of a function needing defining – and the simplest way to turn on the warnings reversibly, I’ll happily look at anything that could easily be cured in that respect and update the repository… but remember I’m primarily a Windows C-coder guy, much of this stuff does not come easy to me – I’d imagine that much is obvious by now.

And thanks for your interest and help.

Pete

From: davydnorris [mailto:notifications@github.com] Sent: 05 March 2019 22:15 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

@scargill https://github.com/scargill I am looking at yours but have my own code drop that's running a week late. As soon as I get that sorted I'll have a play.

As mentioned before, I tried to compile yours and got a ton of warnings. One of the things I've found is that undeclared functions can affect compiler optimisations, and you have a lot of those because your makefile suppressed the warnings.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-469879714 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUg0eGphy1Ikg1W9USoTTz1h6EpU83ks5vTuxSgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUgxDiDT-qbwZDK36baSVE2Slnqn7Uks5vTuxSgaJpZM4bHaSu.gif

fvpalha commented 5 years ago

Hi.

I can see that @davydnorris knows how to evaluate the quality of third-party code. But does he know how to help?

I think the main files are the "Makefile" and the "main.c" for rBoot to work in SDK 3.1.0.

“It was pride that changed angels into devils; it is humility that makes men as angels.” — St. Augustine

Regards.

scargill commented 5 years ago

I only hope that Davynorris or someon can help with what SHOULD be an easy problem - my (large) project works a treat in SDK 2.1 and has worked in all previous versions - but I cannot move on - surewly the point of SDK updates is to make things better, not have people jump through hoops to upgrade. I've been unable up to now to get anyone to give a simple, working answer. People say the new SDK has clawed back lots of room - FINE if you can actaully get a compilation to complete. I've not been able to - I'm not sure if my partition table is just incorrect or if it is something else. ake out the pre-init and partition table - go back to SDK 2.1 and it is just fine with a little iram room to spare. I was hoping to get even more by upgrading.

kriegste commented 5 years ago

Have you tried removing parts of your project? Commenting out stuff. Putting a "return" as first line in a function. I mean, several functions. Just to make it smaller and see if the compiler still complains.

scargill commented 5 years ago

Hi Kriegste – somewhat pointless – the point of upgrading is to fit MORE in, not less. Ta.

Pete

From: kriegste [mailto:notifications@github.com] Sent: 06 March 2019 10:49 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Upgrading to nonos SDK 3.10 (#212)

Have you tried removing parts of your project? Commenting out stuff. Putting a "return" as first line in a function. I mean, several functions. Just to make it smaller and see if the compiler still complains.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/212#issuecomment-470061291 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUg1BLjvK-P0NHkq4oKUARfwTeqzrMks5vT50cgaJpZM4bHaSu . https://github.com/notifications/beacon/ABzUgx7xxKxgGFrjd2CgCGUCo-cO3Fuwks5vT50cgaJpZM4bHaSu.gif

davydnorris commented 5 years ago

Hi Kriegste – somewhat pointless – the point of upgrading is to fit MORE in, not less. Ta.

Actually @kriegste is right - the point is to get something to compile at all, and THEN fit more in :-)

Have you at any point got your code to compile and load using 3.1 regardless of size? Let's get that happening first and then analyse where where the iram is going.

eriksl commented 5 years ago

Eriksl - you have me confused - up to now I've ben working on the asumption that this was required and nothing else. Clealry below is not QUITE right as it won't compile - the usual "won't fit IRAM" message.

but now you've introduced something called partition_items[] - care to elaborate for non-Linux tpyes like me?

#define SDK_RF_CAL_ADDR 0x3FB000
#define SDK_PHY_DATA_ADDR 0x3FC000
#define SDK_PARAM_ADDR 0x3FD000
#define SPI_FLASH_SIZE_MAP FLASH_SIZE_32M_MAP_1024_1024
#define SDK_PRIV_PARAM_ADDR 0xFC000
#define SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM SYSTEM_PARTITION_CUSTOMER_BEGIN

static const partition_item_t p_table[] = {
{ SYSTEM_PARTITION_BOOTLOADER, 0x0, 0x2000 },
{ SYSTEM_PARTITION_RF_CAL, SDK_RF_CAL_ADDR, 0x1000 },
{ SYSTEM_PARTITION_PHY_DATA, SDK_PHY_DATA_ADDR, 0x1000 },
{ SYSTEM_PARTITION_SYSTEM_PARAMETER, SDK_PARAM_ADDR, 0x3000 },
{ SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM, SDK_PRIV_PARAM_ADDR, 0x1000 },
};

void user_pre_init(void)
{
if(!system_partition_table_regist(p_table, sizeof(p_table)/sizeof(p_table[0]), SPI_FLASH_SIZE_MAP)) {
os_printf("system_partition_table_regist fail\r\n");
while(1);
}
}

You keep insisting you're "not a linux guy", but almost anything I mention has nothing to do with Linux at all.

I never said creating a partition table would by miracle free up tons of IRAM space. So if you just add this and compile, it's to be expected that you still run out of IRAM space and the linker (not the compiler) will complain. Be happy it does that, otherwise you wouldn't now and your code would just crash at some point without a hint about the cause.

What I did say is that in recent 3.x commits a lot of IRAM space was freed up from the SDK code. And so your project is more likely to fit. And to be able to run 3.x you need to have the partition table.

One step at a time.

eriksl commented 5 years ago

Eriksl - you have me confused - up to now I've ben working on the asumption that this was required and nothing else. Clealry below is not QUITE right as it won't compile - the usual "won't fit IRAM" message.

but now you've introduced something called partition_items[] - care to elaborate for non-Linux tpyes like me?

#define SDK_RF_CAL_ADDR 0x3FB000
#define SDK_PHY_DATA_ADDR 0x3FC000
#define SDK_PARAM_ADDR 0x3FD000
#define SPI_FLASH_SIZE_MAP FLASH_SIZE_32M_MAP_1024_1024
#define SDK_PRIV_PARAM_ADDR 0xFC000
#define SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM SYSTEM_PARTITION_CUSTOMER_BEGIN

static const partition_item_t p_table[] = {
{ SYSTEM_PARTITION_BOOTLOADER, 0x0, 0x2000 },
{ SYSTEM_PARTITION_RF_CAL, SDK_RF_CAL_ADDR, 0x1000 },
{ SYSTEM_PARTITION_PHY_DATA, SDK_PHY_DATA_ADDR, 0x1000 },
{ SYSTEM_PARTITION_SYSTEM_PARAMETER, SDK_PARAM_ADDR, 0x3000 },
{ SYSTEM_PARTITION_CUSTOMER_PRIV_PARAM, SDK_PRIV_PARAM_ADDR, 0x1000 },
};

void user_pre_init(void)
{
if(!system_partition_table_regist(p_table, sizeof(p_table)/sizeof(p_table[0]), SPI_FLASH_SIZE_MAP)) {
os_printf("system_partition_table_regist fail\r\n");
while(1);
}
}

Now, about using rboot. I already explained this to you before. Rboot is a mechanism that does not use any of the SDK OTA features. So for the SDK you need to make it look like it's a "plain" image. The image, as seen from the SDK code, is the rboot code + your image, it cannot distinguish between the two. So don't confuse it.

So, using rboot, your partition table NEEDS to be something like this (add more "user" partitions at will, but these are the bare minimum):

static const partition_item_t partition_items[] =
{
    {   SYSTEM_PARTITION_RF_CAL,                RFCAL_OFFSET,               RFCAL_SIZE,             },
    {   SYSTEM_PARTITION_PHY_DATA,              PHYDATA_OFFSET,             PHYDATA_SIZE,           },
    {   SYSTEM_PARTITION_SYSTEM_PARAMETER,      SYSTEM_CONFIG_OFFSET,       SYSTEM_CONFIG_SIZE,     },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 0,    USER_CONFIG_OFFSET,         USER_CONFIG_SIZE,       },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 1,    OFFSET_OTA_BOOT,            SIZE_OTA_BOOT,          },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 2,    OFFSET_OTA_RBOOT_CFG,       SIZE_OTA_RBOOT_CFG,     },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 3,    OFFSET_OTA_IMG_0,           SIZE_OTA_IMG,           },
    {   SYSTEM_PARTITION_CUSTOMER_BEGIN + 4,    OFFSET_OTA_IMG_1,           SIZE_OTA_IMG,           },
};
eriksl commented 5 years ago

I'm using RBOOT, too. I am using NON SDK 2.2.x commit 34f1abd (12/27/2018). I'm still not sure on upgrading to the NONOS SDK 3.1.0

The project esp_nano_httpd_fota can be an alternative to RBOOT.

It can be done quite easily, see my partition table and it will work. I don't see any necessity to drop rboot.

eriksl commented 5 years ago

While I think it's important to actually understand the partition table, which is really very simple- it's just a short list mapping addresses to various sectors of flash needed by the SDK- I can see it being a little confusing if you don't already have these locations defined in your project.

I would like to add to that, that the partition table serves two purposes. One is to signal area's of the flash memory to SDK, so they can use it (and your code won't) and another purpose is to protect the flash areas (from your own project, data) from getting overwritten. I am not completely sure how that's achieved, but at least it's good to have your flash layout documented (like you say).

For a 4MB ESP8266 (eg ESP-12E) and rBoot with 512KB roms, all you have to do is, in user_main.c, make it look like this:

I never use rboot this way. It's a big hassle. Always having to generate two different images and make sure you're flashing the correct one. So I make sure my devices always have at least 2 Mb and make use of the "bigflash" feature from rboot, where you can use just one image and then rboot takes care to set up the propper address mapping. @scargill if you're not already the bigflash feature, I would highly recommend it.

eriksl commented 5 years ago

Actually @someburner, there are a few things you would need to change:

  • if you're using rBoot, you need two sectors for the boot ROM so the first line needs to be changed to reflect the larger size: { SYSTEM_PARTITION_BOOTLOADER, 0x0, 0x2000 },

and you also need to include the actual code partitions in this list, which for an OTA enabled 4MB 512k system would start at 0x002000 an 0x082000 (0x2000 higher than the base OTA due to rBoot), and would be 512k in size, minus 2k for rBoot and minus whatever size needed for your system or your own parameters, whichever is larger. In this case let's assume the system parameters are largest size at 1+1+3=5k, so our max OTA partition size is 0x80000 - 0x002000 - 0x005000 = 0x079000

#define SYSTEM_PARTITION_OTA_SIZE      0x79000

{ SYSTEM_PARTITION_OTA_1,              0x002000,     SYSTEM_PARTITION_OTA_SIZE },
{ SYSTEM_PARTITION_OTA_2,              0x082000,     SYSTEM_PARTITION_OTA_SIZE },

I don't think you should do it this way. The SDK makes certain assumptions about the predefined partitions. And "OTA" partition is an "SDK OTA" partition and a "bootloader" partition is an "SDK bootloader" partition. I seem to remember I couldn't even get it to work this way and quickly switched to USER partitions (see my example) and then it works. The SDK code does not mind if bootloader or "OTA" partitions are missing. The SDK code just assumes a non-SDK image, which, as seen from the SDK code, it actually true. The SDK code starts the rboot loader + the image, it does not know about rboot. After rboot is started just like a normal image, reboot "trampolines" to your own image and the SDK code does not see that.

eriksl commented 5 years ago

c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: build/app_0.out section .text' will not fit in regioniram1_0_seg' collect2.exe: error: ld returned 1 exit status mingw32-make.exe: *** [build/app_0.out] Error 1

Just as I've had with previous attempts to upgrade the SDK. Ideas, anyone???

That is because you still did not adapt your loadscript to the new compilation options that are used building the v3 SDK. If you don't change the load script, almost all functions will end up in IRAM, even though you did not specify them as such. But if you do adapt the load script, you'll see you'll end up actually with MORE free IRAM because many SDK functions that end up in IRAM, are no longer linked in, because they're not required by your project.

Als you need to add --gc-sections to your linker command line to make this work. If you have a line with LDFLAGS in your Makefile "somewhere", add this: "-Wl,--gc-sections". While you're at it, also add "-Wl,--size-opt". That also frees up additional IRAM (experimental). Don't type the quotes, but copy&paste the rest, it won't work if spaces are added or removed etc.

This is an example of a working load script. You will need to adjust the sections start addresses and sizes, probably the path to the include file at the bottom and maybe a few other things at all. Espressif has these changes in their supplied load scripts in the SDK as well, so it's not rocket science in itself ;-)

/* This linker script generated from xt-genldscripts.tpp for LSP . */
/* Linker Script for ld -N */
MEMORY
{
  dport0_0_seg :                        org = 0x3FF00000, len = 0x10
  dram0_0_seg :                         org = 0x3FFE8000, len = 0x14000
  iram1_0_seg :                         org = 0x40100000, len = 0x8000
  irom0_0_seg :                         org = 0x40202010, len = 0xf7ff0
}

PHDRS
{
  dport0_0_phdr PT_LOAD;
  dram0_0_phdr PT_LOAD;
  dram0_0_bss_phdr PT_LOAD;
  iram1_0_phdr PT_LOAD;
  irom0_0_phdr PT_LOAD;
}

/*  Default entry point:  */
ENTRY(call_user_start)
EXTERN(_DebugExceptionVector)
EXTERN(_DoubleExceptionVector)
EXTERN(_KernelExceptionVector)
EXTERN(_NMIExceptionVector)
EXTERN(_UserExceptionVector)
PROVIDE(_memmap_vecbase_reset = 0x40000000);
/* Various memory-map dependent cache attribute settings: */
_memmap_cacheattr_wb_base = 0x00000110;
_memmap_cacheattr_wt_base = 0x00000110;
_memmap_cacheattr_bp_base = 0x00000220;
_memmap_cacheattr_unused_mask = 0xFFFFF00F;
_memmap_cacheattr_wb_trapnull = 0x2222211F;
_memmap_cacheattr_wba_trapnull = 0x2222211F;
_memmap_cacheattr_wbna_trapnull = 0x2222211F;
_memmap_cacheattr_wt_trapnull = 0x2222211F;
_memmap_cacheattr_bp_trapnull = 0x2222222F;
_memmap_cacheattr_wb_strict = 0xFFFFF11F;
_memmap_cacheattr_wt_strict = 0xFFFFF11F;
_memmap_cacheattr_bp_strict = 0xFFFFF22F;
_memmap_cacheattr_wb_allvalid = 0x22222112;
_memmap_cacheattr_wt_allvalid = 0x22222112;
_memmap_cacheattr_bp_allvalid = 0x22222222;
PROVIDE(_memmap_cacheattr_reset = _memmap_cacheattr_wb_trapnull);

SECTIONS
{
  .dport0.rodata : ALIGN(4)
  {
    _dport0_rodata_start = ABSOLUTE(.);
    *(.dport0.rodata)
    *(.dport.rodata)
    _dport0_rodata_end = ABSOLUTE(.);
  } >dport0_0_seg :dport0_0_phdr

  .dport0.literal : ALIGN(4)
  {
    _dport0_literal_start = ABSOLUTE(.);
    *(.dport0.literal)
    *(.dport.literal)
    _dport0_literal_end = ABSOLUTE(.);
  } >dport0_0_seg :dport0_0_phdr

  .dport0.data : ALIGN(4)
  {
    _dport0_data_start = ABSOLUTE(.);
    *(.dport0.data)
    *(.dport.data)
    _dport0_data_end = ABSOLUTE(.);
  } >dport0_0_seg :dport0_0_phdr

  .data : ALIGN(4)
  {
    _data_start = ABSOLUTE(.);
/*  _Pri_3_HandlerAddress = ABSOLUTE(.); */
/*  . = ABSOLUTE(4); */
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d.*)
    *(.data1)
    *(.sdata)
    *(.sdata.*)
    *(.gnu.linkonce.s.*)
    *(.sdata2)
    *(.sdata2.*)
    *(.gnu.linkonce.s2.*)
    *(.jcr)
    _data_end = ABSOLUTE(.);
  } >dram0_0_seg :dram0_0_phdr

  .rodata : ALIGN(4)
  {
    _rodata_start = ABSOLUTE(.);
    *(.sdk.version)
    *(.rodata)
    *(.rodata.*)
    *(.gnu.linkonce.r.*)
    *(.rodata1)
    __XT_EXCEPTION_TABLE__ = ABSOLUTE(.);
    *(.xt_except_table)
    *(.gcc_except_table)
    *(.gnu.linkonce.e.*)
    *(.gnu.version_r)
    *(.eh_frame)
    /*  C++ constructor and destructor tables, properly ordered:  */
    KEEP (*crtbegin.o(.ctors))
    KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
    KEEP (*crtbegin.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
    /*  C++ exception handlers table:  */
    __XT_EXCEPTION_DESCS__ = ABSOLUTE(.);
    *(.xt_except_desc)
    *(.gnu.linkonce.h.*)
    __XT_EXCEPTION_DESCS_END__ = ABSOLUTE(.);
    *(.xt_except_desc_end)
    *(.dynamic)
    *(.gnu.version_d)
    . = ALIGN(4);       /* this table MUST be 4-byte aligned */
    _bss_table_start = ABSOLUTE(.);
    LONG(_bss_start)
    LONG(_bss_end)
    _bss_table_end = ABSOLUTE(.);
    _rodata_end = ABSOLUTE(.);
  } >dram0_0_seg :dram0_0_phdr

  .bss ALIGN(8) (NOLOAD) : ALIGN(4)
  {
    . = ALIGN (8);
    _bss_start = ABSOLUTE(.);
    *(.dynsbss)
    *(.sbss)
    *(.sbss.*)
    *(.gnu.linkonce.sb.*)
    *(.scommon)
    *(.sbss2)
    *(.sbss2.*)
    *(.gnu.linkonce.sb2.*)
    *(.dynbss)
    *(.bss)
    *(.bss.*)
    *(.gnu.linkonce.b.*)
    *(COMMON)
    . = ALIGN (8);
    _bss_end = ABSOLUTE(.);
    _heap_start = ABSOLUTE(.);
/*    _stack_sentry = ALIGN(0x8); */
  } >dram0_0_seg :dram0_0_bss_phdr
/* __stack = 0x3ffc8000; */

  .irom0.text : ALIGN(4)
  {
    _irom0_text_start = ABSOLUTE(.);
    *libmbedtls.a:(.literal.* .text.*)
    *libat.a:(.literal.* .text.*)
    *libcrypto.a:(.literal.* .text.*)
    *libespnow.a:(.literal.* .text.*)
    *libjson.a:(.literal.* .text.*)
    *liblwip.a:(.literal.* .text.*)
    *libmesh.a:(.literal.* .text.*)
    *libnet80211.a:(.literal.* .text.*)
    *libsmartconfig.a:(.literal.* .text.*)
    *libssl.a:(.literal.* .text.*)
    *libupgrade.a:(.literal.* .text.*)
    *libwpa.a:(.literal.* .text.*)
    *libwpa2.a:(.literal.* .text.*)
    *libwps.a:(.literal.* .text.*)
    *libm.a:(.literal .text .literal.* .text.*)
    *(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text .flash.rodata)
    _irom0_text_end = ABSOLUTE(.);
  } >irom0_0_seg :irom0_0_phdr

  .text : ALIGN(4)
  {
    _stext = .;
    _text_start = ABSOLUTE(.);
    *(.UserEnter.text)
    . = ALIGN(16);
    *(.DebugExceptionVector.text)
    . = ALIGN(16);
    *(.NMIExceptionVector.text)
    . = ALIGN(16);
    *(.KernelExceptionVector.text)
    LONG(0)
    LONG(0)
    LONG(0)
    LONG(0)
    . = ALIGN(16);
    *(.UserExceptionVector.text)
    LONG(0)
    LONG(0)
    LONG(0)
    LONG(0)
    . = ALIGN(16);
    *(.DoubleExceptionVector.text)
    LONG(0)
    LONG(0)
    LONG(0)
    LONG(0)
    . = ALIGN (16);
    *(.entry.text)
    *(.init.literal)
    *(.init)
    *(.literal .text .literal.* .text.* .stub .gnu.warning .gnu.linkonce.literal.* .gnu.linkonce.t.*.literal .gnu.linkonce.t.*)
    *(.fini.literal)
    *(.fini)
    *(.gnu.version)
    _text_end = ABSOLUTE(.);
    _etext = .;
  } >iram1_0_seg :iram1_0_phdr

  .lit4 : ALIGN(4)
  {
    _lit4_start = ABSOLUTE(.);
    *(*.lit4)
    *(.lit4.*)
    *(.gnu.linkonce.lit4.*)
    _lit4_end = ABSOLUTE(.);
  } >iram1_0_seg :iram1_0_phdr
}

/* get ROM code address */
INCLUDE "../ld/eagle.rom.addr.v6.ld"
eriksl commented 5 years ago

I am trying follow your suggestions, but yet do not work. The project compile, but the firmware (ROM) does not run in ESP8266.

What do you mean by that?

Maybe you're running into the same issue I ran into lately. When I generate an image for a 512 KB flash device, the image won't start. If I change it into an "1 MB 512-512" image, it can be flashed just fine and also runs fine. It seems the whole thong crashes before even anything of my code is called (tested and debugged) so my possibilities end there. It's also not rboot's fault, because it also happens with a "plain" image (no rboot involved).

eriksl commented 5 years ago

Hi @fvpalha - I don't actually use rBoot, I've just been using 3.1 for ages.

I had a look at your test project, and to be honest it's a bit of a mess. From what I can tell, you have dumped the rBoot source, the driver source supplied by Espressif, and a bunch of other stuff all into one directory. It's impossible to tell why your project isn't working - you need to make it really easy for us to help you!

Set up some subdirectories with the various standard pieces in, and then set up your user directory with your simple sample so that we know what file to look at

In itself it's fine, I also use rboot, the SDK and (now) the toolchain from within the projects directory but then make them git submodules, don't copy them.