Date   

Re: OpenOCD on STM32 boards

Bolivar, Marti
 

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@...> writes:

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:
sudo apt-get install openocd
It's not always wise to trust in your distro's openocd. It has been hard
to get support patches merged into upstream openocd, so the downstream
version in the Zephyr SDK is usually the right one to use.

Obviously I am doing something silly wrong. Can anyone give me a hint?
Thanks
Use the openocd in the Zephyr SDK. You can do this even if you're not
using the Zephyr SDK's toolchain -- as long as ZEPHYR_SDK_INSTALL_DIR
points at a Zephyr SDK install, the build system will use its host tools
(like openocd) even if ZEPHYR_TOOLCHAIN_VARIANT != zephyr.


Zephyr Release 2.1: Status: Merge window closing this Friday, Nov 8th!

David Leach
 

A reminder that the feature merge window to Zephyr will be closing this Friday (November 8th). For more information on milestone dates please refer to the program management wiki page:

 

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

 

If there are outstanding PRs that the authors want in the 2.1 release than tag them with the “v2.1.0” milestone and work with the maintainers to approve and merge the PR.

 

Issues statistics:

 

Priority

Count

Change from last week

High

2

-

Medium

38

+1

Low

161

+9

No priority

2

-1

 

Over the last 4 weeks we have opened 99 new issues and closed 127 with 203 active issues.

 

Note that the release criteria includes zero high priority bugs and <20 medium priority bugs so if you are assigned a bug in these priority buckets please give them the appropriate attention.

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 


OpenOCD on STM32 boards

Lawrence King
 

Today I decided to bring up a STLML476 board, specifically the Nucleo-L476RG board.

 

Compile went cleanly

west build -b nucleo_l476rg samples/basic/blinky

Then after connecting the board I tried

              west flash

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:

              sudo apt-get install openocd

And openocd and a few other packages happily  installed.

 

Now ‘west flash’ complains:

-- west flash: rebuilding

ninja: no work to do.

-- west flash: using runner openocd

-- runners.openocd: Flashing file: /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex

Open On-Chip Debugger 0.10.0

Licensed under GNU GPL v2

For bug reports, read

              http://openocd.org/doc/doxygen/bugs.html

/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/nucleo_l476rg/support/openocd.cfg:1: Error: Can't find board/st_nucleo_l4.cfg

in procedure 'script'

at file "embedded:startup.tcl", line 60

at file "/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/nucleo_l476rg/support/openocd.cfg", line 1

ERROR: command exited with status 1: /usr/bin/openocd -f /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/nucleo_l476rg/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown

 

 

The top of the openocd.cfg files (line 1) says:

source [find board/st_nucleo_l4.cfg]

 

I hunted around for the ‘missing’ file “board/st_nucleo_l4.cfg” to no avail. I also tried several other boards that use openocd and found similar missing include files.

 

I did confirm that the board is correctly connected and visible:

$ sudo lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 008: ID 0483:374b STMicroelectronics ST-LINK/V2.1 (Nucleo-F103RB)

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

 

Obviously I am doing something silly wrong. Can anyone give me a hint? Thanks

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


API meeting: agenda

Carles Cufi
 

Hi all,

This week we will look at GPIO:

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: A question about configuring a USB virtual console in DTS? #dts #defconfig

Andrei
 

Hi,

On Mon, Nov 04, 2019 at 02:06:04PM -0800, nanjunneo@... wrote:
Is it compulsory to add the node "virtualcom" to configure a USB virtual
com port via USB-OTG-HS for STM32F407 under Zephyr 2.0.99?

I got the following code in DTS from a partner but it cannot be built
properly. Error indicates that virtualcom does not have necessary
properties. (It is said that the code was compiled in version 1.13.0.)
.......
    usb_cdc: virtualcom {
        label = "CDC_ACM";
    };
You can just remove virtualcom stuff,
samples/subsys/usb/console/prj.conf should assign right console with:

CONFIG_UART_CONSOLE_ON_DEV_NAME="CDC_ACM_0"

Best regards
Andrei Emeltchenko


    chosen {
        zephyr,console = &usb_cdc;
        zephyr,sram = &sram0;
        zephyr,flash = &flash0;
        zephyr,ccm = &ccm0;
    };
.......
......
&usbotg_hs {
    status = "ok";
};

Moreover, the sample code (usb/console) only requires to add configure
entries to defconfig so that I got confused. Thanks for your reply in
advance!
_._,_._,_


A question about configuring a USB virtual console in DTS? #dts #defconfig

nanjunneo@...
 

Is it compulsory to add the node "virtualcom" to configure a USB virtual com port via USB-OTG-HS for STM32F407 under Zephyr 2.0.99?

I got the following code in DTS from a partner but it cannot be built properly. Error indicates that virtualcom does not have necessary properties. (It is said that the code was compiled in version 1.13.0.)
.......
    usb_cdc: virtualcom {
        label = "CDC_ACM";
    };

    chosen {
        zephyr,console = &usb_cdc;
        zephyr,sram = &sram0;
        zephyr,flash = &flash0;
        zephyr,ccm = &ccm0;
    };
.......
......
&usbotg_hs {
    status = "ok";
};

Moreover, the sample code (usb/console) only requires to add configure entries to defconfig so that I got confused. Thanks for your reply in advance!


Re: Error in services launch sequence #debugging #eclipse #gdb

fashtop3@...
 

All I did was to uncheck the "start pyOCD locally"


Zephyr Release 2.1: Status: Merge window closing Nov 8th

David Leach
 

A reminder that the feature merge window to Zephyr will be closing next Friday (November 8th). For more information on milestone dates please refer to the program management wiki page:

 

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

 

 

Issues statistics:

 

Priority

Count

Change from last week

High

2

-

Medium

37

+1

Low

152

+2

Uncategorized

3

+3

 

Over the last 4 weeks we have opened 103 new issues and closed 123 with 194 active issues.

 

Note that the release criteria includes zero high priority bugs and <20 medium priority bugs so if you are assigned a bug in these priority buckets please give them the appropriate attention.

 

 

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 


Logger flash backend

Ilan Ganor <ilan@...>
 

Hello 


Nordic presented some of their implementations using the Logger framework which support features like:

logger backend flash (saving logger data to flash)
and save logger definitions 

those are very valuable features

does anyone knows: 

1. if and where can I get this code ?

2. is Zephyr planning to support that officially (currently there is support for Serial, Telnet and RTT)

thank you 


Zephyr Release 2.1: Status

David Leach
 

A reminder that the feature merge window to Zephyr will be closing on November 8th (two short weeks away). Please keep this date in mind for any items you may be working on that you wish to be included in the 2.1 release. For more information on milestone dates please refer to the program management wiki page:

 

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

 

 

Issues statistics:

 

Priority

Count

Change from last week

High

2

+1

Medium

36

+2

Low

150

-12

 

Over the last 4 weeks we have opened 90 new issues and closed 126 with 188 active issues.

 

Note that the release criteria includes zero high priority bugs and <20 medium priority bugs so if you are assigned a bug in these priority buckets please give them the appropriate attention.

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 


Re: Ethernet samples/demo

rdsingh@...
 

Tried to run gptp with the following results - 
rajas-imac:zephyr rdsingh$ west build -b sam_e70_xplained samples/net/gptp --pristinefdfadfadfad

Zephyr version: 2.0.99

-- Found PythonInterp: /Users/rdsingh/.pyenv/versions/3.7.0/bin/python (found suitable version "3.7.0", minimum required is "3.4") 

-- Selected BOARD sam_e70_xplained

-- Found west: /Users/rdsingh/.pyenv/versions/3.7.0/bin/west (found suitable version "0.6.3", minimum required is "0.6.0")

-- Loading /Users/rdsingh/zephyrDev/zephyrproject/zephyr/boards/arm/sam_e70_xplained/sam_e70_xplained.dts as base

-- Overlaying /Users/rdsingh/zephyrDev/zephyrproject/zephyr/dts/common/common.dts

Devicetree configuration written to /Users/rdsingh/zephyrDev/zephyrproject/zephyr/build/zephyr/include/generated/generated_dts_board.conf

 

warning: ETH_SAM_GMAC_MAC0 (defined at drivers/ethernet/Kconfig.sam_gmac:97) was assigned the value

'0xFC' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC0.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC1 (defined at drivers/ethernet/Kconfig.sam_gmac:102) was assigned the value

'0xC2' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC1.html (which is

updated regularly from the master branch). See the 'Setting configuration values'Parsing Kconfig tree in /Users/rdsingh/zephyrDev/zephyrproject/zephyr/samples/net/gptp/Kconfig

Loaded configuration '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/boards/arm/sam_e70_xplained/sam_e70_xplained_defconfig'

Merged configuration '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/samples/net/gptp/prj.conf'

Merged configuration '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/samples/net/gptp/boards/sam_e70_xplained.conf'

Configuration saved to '/Users/rdsingh/zephyrDev/zephyrproject/zephyr/build/zephyr/.config'

 section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC2 (defined at drivers/ethernet/Kconfig.sam_gmac:107) was assigned the value

'0x3D' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC2.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC3 (defined at drivers/ethernet/Kconfig.sam_gmac:112) was assigned the value

'0xBC' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC3.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC4 (defined at drivers/ethernet/Kconfig.sam_gmac:117) was assigned the value

'0x8C' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC4.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: ETH_SAM_GMAC_MAC5 (defined at drivers/ethernet/Kconfig.sam_gmac:122) was assigned the value

'0xAE' but got the value ''. You can check symbol information (including dependencies) in the

'menuconfig' interface (see the Application Development Primer section of the manual), or in the

Kconfig reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_ETH_SAM_GMAC_MAC5.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

 

warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but

got the value 'n'. You can check symbol information (including dependencies) in the 'menuconfig'

interface (see the Application Development Primer section of the manual), or in the Kconfig

reference at

http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_TEST_RANDOM_GENERATOR.html (which is

updated regularly from the master branch). See the 'Setting configuration values' section of the

Board Porting Guide as well.

-- The C compiler identification is GNU 6.3.1

-- The CXX compiler identification is GNU 6.3.1

-- The ASM compiler identification is GNU

-- Found assembler: /Users/rdsingh/arm-none-eabi/bin/arm-none-eabi-gcc

-- Cache files will be written to: /Users/rdsingh/Library/Caches/zephyr

-- Configuring done

-- Generating done

-- Build files have been written to: /Users/rdsingh/zephyrDev/zephyrproject/zephyr/build

-- west build: building application

[1/177] Preparing syscall dependency handling

 

[172/177] Linking C executable zephyr/zephyr_prebuilt.elf

Memory region         Used Size  Region Size  %age Used

           FLASH:      148200 B         2 MB      7.07%

            SRAM:       59352 B       384 KB     15.09%

        IDT_LIST:          72 B         2 KB      3.52%

[177/177] Linking C executable zephyr/zephyr.elf

rajas-imac:zephyr rdsingh$ west flash

Connected a serial Terminal to the board -
uart:~$ [00:00:00.000,000] 
uart:~$ [00:00:00.000,000] <inf> i2c_sam_twihs: Device I2C_0 initialized
uart:~$ uart:~$ [00:00:00.001,000] <inf> eth_sam: MAC: fc:c2:3d:0b:fe:34
uart:~$ [00:00:00.001,000] <inf> eth_sam: Queue 0 activated
uart:~$ [00:00:00.001,000] <inf> eth_sam: Queue 1 set to idle
uart:~$ [00:00:00.001,000] <inf> eth_sam: Queue 2 set to idle
uart:~$ [00:00:00.001,000] <inf> eth_sam_phy: Soft Reset of ETH PHY
uart:~$ [00:00:00.091,000] <inf> eth_sam_phy: PHYID: 0x221561 at addr: 0
uart:~$ uart:~$ ***** Booting Zephyr OS build zephyr-v2.0.0-1321-g8bc3b6f6732c *****
[00:00:03.107,000] <inf> eth_sam_phy: common abilities: speed 100 Mb, full duplex
uart:~$ [00:00:03.117,000] <inf> net_config: Initializing network
uart:~$ [00:00:03.117,000] <inf> net_config: IPv4 address: 192.0.2.1
uart:~$ [00:00:03.207,000] <inf> net_config: IPv6 address: fe80::fec2:3dff:fe0b:fe34
uart:~$ [00:00:03.217,000] <inf> net_config: IPv6 address: fe80::fec2:3dff:fe0b:fe34
uart:~$ uart:~$ [00:00:04.113,000] <wrn> net_gptp: Reset Pdelay requests
uart:~$ uart:~$ [00:00:05.119,000] <wrn> net_gptp: Reset Pdelay requests
uart:~$ uart:~$ [00:00:06.125,000] <wrn> net_gptp: Reset Pdelay requests
uart:~$ uart:~$ [00:00:07.131,000] <wrn> net_gptp: Reset Pdelay requests
uart:~$ uart:~$ [00:00:08.137,000] <wrn> net_gptp: Reset Pdelay requests
uart:~$ uart:~$ [00:00:09.143,000] <wrn> net_gptp: Reset Pdelay requests
uart:~$ uart:~$ [00:00:10.149,000] <wrn> net_gptp: Reset Pdelay requests
uart:~$ uart:~$


Then in a Linux machine got AVnu/ptp, compiled and ran - 
~/gptp/build$ sudo ./gptp enp3s0 -F gptp_cfg.ini
INFO : GPTP [17:55:35:130] gPTP starting
INFO : GPTP [17:55:35:132] priority1 = 248
INFO : GPTP [17:55:35:132] announceReceiptTimeout: 3
INFO : GPTP [17:55:35:132] syncReceiptTimeout: 3
INFO : GPTP [17:55:35:132] LINKSPEED_100MB - PHY delay
TX: 1044 | RX: 2133
INFO : GPTP [17:55:35:132] LINKSPEED_1G - PHY delay
TX: 184 | RX: 382
INFO : GPTP [17:55:35:132] neighborPropDelayThresh: 10000
INFO : GPTP [17:55:35:132] syncReceiptThreshold: 8
INFO : GPTP [17:55:35:132] SyncFollowUp with negative correction field: forbidden
ERROR : GPTP [17:55:35:132] Failed to configure timestamping: Operation not supported
ERROR : GPTP [17:55:35:132] post_init failed

ERROR : GPTP [17:55:35:132] failed to initialize port

Any help is much appreciated. I am trying to get at least a dhcpV4_client running without any luck so far.

I am not very experienced with Zephyr. But I am experienced in compiling Linux on embedded systems using buildroot.

I am experienced on Networking and the concepts.

I would like to know how the hardware configuration is done on KConfig in zephyr. Please point me to documentation on that.

best regards,
RDS


Re: Ethernet samples/demo

rdsingh@...
 

Jukka,
After clicking on Reply, I realized it is sent to you and not to the group. Please accept my apologies.

regards,

RDS


API meeting: Agenda

Carles Cufi
 

Hi all,

This week we will look at:

- V4Z: Update on comments, merge if there is no objections
- https://github.com/zephyrproject-rtos/zephyr/pull/17194

- EEPROM API proposal
- https://github.com/zephyrproject-rtos/zephyr/pull/19972

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Ethernet samples/demo

Jukka Rissanen
 

Hi,

I have been using sam-e70 with some of the samples, mainly gptp and
echo-server. There have been regressions in past with the networking
samples as currently we have no automatic testing of these samples. The
situation will improve with this PR
https://github.com/zephyrproject-rtos/zephyr/pull/19677 after it is
merged.

If you find some sample that does not work with sam-e70, please file an
issue (one / sample please) for those. All the generic samples that can
be run on Etherhet should work with sam-e70 board.

Cheers,
Jukka

On Mon, 2019-10-21 at 19:37 -0700, rdsingh@... wrote:
Hi all,
Wondering if SAME70 XPLD board has been tested with Ethernet
Networking Samples in the repository.
So far, all the examples that I have tried did not work for me.
Wondering if I am missing something here.

regards,
RDS


Ethernet samples/demo

rdsingh@...
 

Hi all,
Wondering if SAME70 XPLD board has been tested with Ethernet Networking Samples in the repository. 
So far, all the examples that I have tried did not work for me.
Wondering if I am missing something here.

regards,
RDS


Re: Bluetooth mcumgr SMP DFU speed #ble

nick.ward@...
 


Usage of optional 'erase-block-size' flash nodes property

Erwan Gouriou
 

Hi all,

Optional property 'erase-block-size' is used to describe the minimum size of flash sector on which an erase operation could be applied. It is generated as a device tree generic define DT_FLASH_ERASE_BLOCK_SIZE (made generic through the use of chosen 'zephyr,flash').
It is optional since, on some parts (stm32f4, for instance), flash layout is made of several sectors of variable size and hence it cannot be provided.

So here is the issue since, on one side, we have a zephyr generic define, and on the other side, we have parts on which it does not exist. Problem is that it could happen that people use it in generic zephyr components, while it is not a generic property (cf last example: [1]).

Another issue with this define is that it appears to be simple and handy to use, but it is actually misleading since it is only available on embedded flash. So any flash based application, if trying to use it will fail on external flash.
Flash API actually provides an alternate, robust and generic 'flash_area_get_sectors' that will provide the same information with few more computations. And this is the solution to be used.

Unfortunately, there is no automatic way to prevent people using misleading DT_FLASH_ERASE_BLOCK_SIZE.

So the question I'm raising to you is how to avoid facing this issue every 3 months.
Once idea would be to remove it, but it is actually used in device specific embedded flash drivers where it does make sense.

If you're interested, don't hesitate to answer this mail, comment in related issue [1] or join dev_meeting next week.

Thanks
Erwan



Re: Recursive checkout with West

Jørn Villesen Christensen <extjvc@...>
 

On 17/10/2019 18.51, Bolivar, Marti wrote:
I'm trying to get a beta in people's hands in early November. This will
be available on PyPI, but you will need to manually install a
pre-release version of west with 'pip3 install --pre west' or so to get
it. It's not in 0.6.3.

I want to give it some "soak time" this way before we release an
official version of west with this feature, because it will be harder to
make big changes based on user feedback after that release happens.

I will send mail to the lists with details at that time.
Cool. Thank you :-)


~Jørn


Re: Recursive checkout with West

Bolivar, Marti
 

Jørn Villesen Christensen via Lists.Zephyrproject.Org
<extjvc=trifork.com@...> writes:

Hi Marti,

Thank you too - and for the links :)

On 16/10/2019 22.43, Bolivar, Marti wrote:
As far as I can tell, the existing proposal described on GitHub
satisfies these requirements:

1. one west.yml
2. it's short
3. you don't have to manually track changes in other west.yml files

I was not aware of this work that you are doing. I only saw the #221
issue (West manifest imports) which (afaIcs) is more about merging
several manifests files rather than the import feature you are
documenting.

I read your documentation (most of it at least :) ) and it indeed
sounds like the thing I was looking for. So thank you. Would you have
a road map for when this feature would be implemented?

(I tested with my west 0.6.3 and it does not seem to recognize the
import keyword.)
I'm trying to get a beta in people's hands in early November. This will
be available on PyPI, but you will need to manually install a
pre-release version of west with 'pip3 install --pre west' or so to get
it. It's not in 0.6.3.

I want to give it some "soak time" this way before we release an
official version of west with this feature, because it will be harder to
make big changes based on user feedback after that release happens.

I will send mail to the lists with details at that time.

I think your proposal is indeed what I am looking for. Yes, there is a
slight functional difference whether it is recursive or not. I just
assumed recursive would be beneficial / logical, but you made a point
that it might not be what everybody wants. I think for our project the
one-level import may be sufficient. At least for now.
OK, great, that's really good to hear. I hope you will try the
pre-release when it's available and let me know what you think.

Thanks,
Marti


Re: Recursive checkout with West

Jørn Villesen Christensen <extjvc@...>
 

Hi Marti,

Thank you too - and for the links :)

On 16/10/2019 22.43, Bolivar, Marti wrote:
Hi Jørn,

Thank you for taking the time to write down your thoughts.

Jørn Villesen Christensen via Lists.Zephyrproject.Org

My vision / idea (a.k.a. recursive parsing):
I envisioned that we had a top level project with a west.yml. Upon running west update, west would check out project dependencies (as today), but then it would examine each of these projects to see if they would contain a west.yml. If so, it would run a west update on those as well, ignoring that it is already in a (parent) west project.

Doing this automatically would be undesirable to at those users who do
not want to automatically include all upstream modules in their
downstream (e.g. if they want to exclude modules that are only relevant
to arches, socs, etc. that they are targeting, for bandwidth
optimization or due to License/IP allergies).

Hm... I just assumed that if you were including a project you would always a) need all dependencies of that project, and b) be ok with their licenses. But ok... point accepted :-)


=== Longer story: ===

The main benefits of recursive parsing (as I see it):
The top level project would only have a single west.yml file to maintain - and it would be short. It would not need to keep track of all dependency dependencies. If a project dependency is to be updated, you would not need to run the merge command again (and resolve possible conflicts from intermittent changes).

As far as I can tell, the existing proposal described on GitHub
satisfies these requirements:

1. one west.yml
2. it's short
3. you don't have to manually track changes in other west.yml files

I was not aware of this work that you are doing. I only saw the #221 issue (West manifest imports) which (afaIcs) is more about merging several manifests files rather than the import feature you are documenting.

I read your documentation (most of it at least :) ) and it indeed sounds like the thing I was looking for. So thank you. Would you have a road map for when this feature would be implemented?

(I tested with my west 0.6.3 and it does not seem to recognize the import keyword.)

If that doesn't work for you, can you explain more about why your
specific proposed mechanism of automatically and recursively pulling in
all west.yml files in all subprojects is better?

I think your proposal is indeed what I am looking for. Yes, there is a slight functional difference whether it is recursive or not. I just assumed recursive would be beneficial / logical, but you made a point that it might not be what everybody wants. I think for our project the one-level import may be sufficient. At least for now.

(Note: I originally thought that these explicit imports would not be
recursive to start out, but I'm going to try to make that work.)

When I read your proposal I was thinking that the recursive-feature could be optional:

  • If import is boolean (today), this could be changed to enumeration with following keywords:
    • false, off, none: No import is done - same as false today.
    • true, top: Same as true today - yielding an error if any sub projects use import keyword
    • top-ignore: Same as true today but without yielding an error is sub projects use import keyword. Just ignore it.
    • recursive: Recursive import.
  • If import is mapping, one could add a key recursive => {false / false-ignore / true}
I am not sure whether there is need for this detailed control; I just wanted to share the idea.
Challenges in build procedure:
I think it's not really a build system problem as much as it is a west
init / west update problem.

The build sytem just uses 'west list' to get the default ZEPHYR_MODULES:

https://docs.zephyrproject.org/latest/guides/modules.html

Since 'west list' will still work the same way after this feature is
implemented, I expect no impact on zephyr's build system.

The meat of the feature is making west init and west update work
properly when there multiple files, some of which may also need to be
cloned from separate repositories.

Thank you for the info (west list and build system). I'll take your word for it that the challenge lies with init and update. :-) 

BR
Jørn