Re: [riot-devel] CC2538dk Riotboot support
Hi Brenton, I noticed there is `-e` in `FFLAGS` which performs a full erase of the rom so flashing a second slot while the first one or the bootloader is there cannot work. We removed this full erase from all flashers for boards using `riotboot`. If the flasher erases only what is required for flashing it could be removed from the default configuration. And it was the case for `edbg/openocd/jlink`. Regards, Gaëtan So you can try without the `-e` in `FFLAGS` and see if first flashing `slot1` works and if it is also not destroying your normal workflow ? On 5/31/19 1:50 PM, Brenton Chetty wrote: Hi Gaëtan, i managed to get the tests/riotboot to pass whilst using 'riotboot/flash-combined-slot0'. I also used the '-a' option For 'cc2538-bsl.py'. This allowed me to use the 'riotboot/flash-slot0' successfully. However, i couldn't get slot 1 working. How do think i should approach this problem. And currently i can only use 'riotboot/flash-slot0' whilst using the '-a' option For 'cc2538-bsl.py'. What is the RIOT approach to implementing this? With regards Brenton On Mon, May 27, 2019 at 2:31 PM Gaëtan Harter wrote: Hi Brenton, if you only use the default `riotboot/flash` or `flash` in `tests/riotboot` targets, you do not need flasher changes. But you should not use `riotboot/flash-slot0` and `riotboot/flash-slot1` targets for the moment. To have the support declared and merged in RIOT, it also needs to support flashing the `slot-` firmwares alone. These require having flasher that can flash with an offset`. For `cc2538-bsl.py` it looks like there is the `-a` option for this. Maybe changing it to use `IMAGE_OFFSET` if set would be enough. An example is in https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15 The `flash.sh` is currently using `jlink` without using the common `jlink` scripts thing, it is in my todo list after https://github.com/RIOT-OS/RIOT/pull/11554 to migrate to use the common one where applicable. Cheers, Gaëtan On 5/24/19 2:32 PM, Francisco Acosta wrote: Hi Brenton! So far I remember we didn't take it into account, and I don't know if someone is taking care of it. As far as I know, there are two ways of supporting that CPU: 1. The way we do it now, which is linking the image in another start address so the bootloader can recognise it and boot it. 2. Modify the start address on the CC2538 register dedicated to this. This might be a bit tricky but also interesting for the sake of research and compatibility. However, I'd advice the first option to have the full benefits of the bootloader and struggling less with the particular settings on that chip. Overall, the steps would be the following: 1. Adapt the linker scripts to succeed tests/cortexm_common_ldscript. This consists on making the linker scripts on cpu/cc2838/ldscripts comply with cpu/cortexm_common/ldscrpts/cortexm.ld. You might take a look how is it done for stm32 or sam0 families. 2. Provide the length and start variables to link slots correctly: - ROM_LEN - RAM_LEN - ROM_START_ADDR - RAM_START_ADDR Again, take a look on the supported CPUs as examples. 3. Make tests/riotboot pass 4. Perform a firmware update or flash different firmwares with different versions so the bootloader choses the newest. Optionally you might want to test if the WIP SUIT update format works. Don't hesitate to make more questions if you have some! Cheers, Paco. On 24/05/2019 13:43, Brenton Chetty wrote: Hey guys, has anyone succeeded in providing riotboot support for the cc2538dk board as yet? ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Release 2019.07 - dates and feature requests
Hi, I would personally like to manage to get the migration to FLASHFILE finally finished https://github.com/RIOT-OS/RIOT/pull/8838 (I only have the tracking PR currently, so it's my fault if it did not move) and the fix for flashers on the board I use for testing the release https://github.com/RIOT-OS/RIOT/pull/10870 as I currently use them for testing anyway. I could need help for that last one if you have examples that put any of the mentioned boards in a no more flashable state with RIOT. Cheers, Gaëtan On 6/1/19 6:42 PM, Dylan Laduranty wrote: Hi all, #11077 and #11085 could be in the incoming release but it will require to have #11075 and #10916 merged first. Hopefully, #11075 should be pretty straightforward and #10916 (which introduces the stack) is in the final review state. Any help with the review and/or test process will be highly appreciated ! Cheers, Le sam. 1 juin 2019 à 01:40, Hauke Petersen a écrit : Hej, big +1! Getting the USB+Ethernet slave mode to work would be a major milestone towards simple to deploy border routers and such. So ~4 more weeks seems doable, right?! Cheers, Hauke On 5/31/19 10:11 PM, Mario Gómez wrote: Hi all! My grain of salt: For high impact features: PR #11085 (Serial console over USB) & PR #11077 (USB CDC ECM support) Those two combined with something like the SAM-BA bootloader (Arduino SAMD bootloader compatible with BOSSA) would allow us to make easy-upgradeable one-chip border-router USB dongles based on the ATSAMR21. USB CDC ECM essentially could remove the need for ethos. Regards, Mario. On Fri, May 31, 2019 at 6:51 AM Kevin Weiss wrote: Dear RIOTers, The release dates for the upcoming release cycle are fixed as follows: - 28.06.2019 - soft feature freeze, for high impact features - 08.07.2019 - hard feature freeze, for all features - 31.07.2019 - Release date Could you please send your suggestions for features which you would like to see merged during this release cycle. Best regards, and happy hacking! Kevin Weiss ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Release 2019.07 - dates and feature requests
Hi, USB support would be a major milestone for RIOT. It would be awesome to have it in the next release. I would like to see the following things in the next release: - LwM2M support, see [1] - Support for WolfSSL (provides secure sockets, DTLS, etc), see [2] I think both are already in a good shape, just missing reviews and testing. Alex [1] https://github.com/RIOT-OS/RIOT/pull/11036 [2] https://github.com/RIOT-OS/RIOT/pull/10308 - Le 1 Juin 19, à 18:42, Dylan Laduranty a écrit : > Hi all, > #11077 and #11085 could be in the incoming release but it will require to have > #11075 and #10916 merged first. > Hopefully, #11075 should be pretty straightforward and #10916 (which > introduces > the stack) is in the final review state. > Any help with the review and/or test process will be highly appreciated ! > Cheers, > Le sam. 1 juin 2019 à 01:40, Hauke Petersen < [ > mailto:hauke.peter...@fu-berlin.de | hauke.peter...@fu-berlin.de ] > a écrit : >> Hej, >> big +1! Getting the USB+Ethernet slave mode to work would be a major >> milestone >> towards simple to deploy border routers and such. >> So ~4 more weeks seems doable, right?! >> Cheers, >> Hauke >> On 5/31/19 10:11 PM, Mario Gómez wrote: >>> Hi all! >>> My grain of salt: >>> For high impact features: >>> PR #11085 (Serial console over USB) & PR #11077 (USB CDC ECM support) >>> Those two combined with something like the SAM-BA bootloader (Arduino SAMD >>> bootloader compatible with BOSSA) would allow us to make easy-upgradeable >>> one-chip border-router USB dongles based on the ATSAMR21. USB CDC ECM >>> essentially could remove the need for ethos. >>> Regards, >>> Mario. >>> On Fri, May 31, 2019 at 6:51 AM Kevin Weiss < [ >>> mailto:kevin.we...@haw-hamburg.de | kevin.we...@haw-hamburg.de ] > wrote: Dear RIOTers, The release dates for the upcoming release cycle are fixed as follows: - 28.06.2019 - soft feature freeze, for high impact features - 08.07.2019 - hard feature freeze, for all features - 31.07.2019 - Release date Could you please send your suggestions for features which you would like to see merged during this release cycle. Best regards, and happy hacking! Kevin Weiss ___ devel mailing list [ mailto:devel@riot-os.org | devel@riot-os.org ] [ https://lists.riot-os.org/mailman/listinfo/devel | https://lists.riot-os.org/mailman/listinfo/devel ] >>> ___ >>> devel mailing list [ mailto:devel@riot-os.org | devel@riot-os.org ] [ >>> https://lists.riot-os.org/mailman/listinfo/devel | >>> https://lists.riot-os.org/mailman/listinfo/devel ] >> ___ >> devel mailing list >> [ mailto:devel@riot-os.org | devel@riot-os.org ] >> [ https://lists.riot-os.org/mailman/listinfo/devel | >> https://lists.riot-os.org/mailman/listinfo/devel ] > -- > Dylan Laduranty > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
