-
Notifications
You must be signed in to change notification settings - Fork 7k
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
[DNM][RFC] dts: Get SoC from dts and not from kconfig generated autoconfig.h #9925
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -109,7 +109,7 @@ | |
#elif defined(CONFIG_SOC_STM32L073XZ) | ||
#define DT_FLASH_SIZE __SIZE_K(192) | ||
#define DT_SRAM_SIZE __SIZE_K(20) | ||
#elif defined(CONFIG_SOC_STM32L475XG) | ||
#elif defined(CONFIG_SOC_STM32L475XG) || defined(SOC_STM32L475XG) | ||
#define DT_FLASH_SIZE __SIZE_K(1024) | ||
#define DT_SRAM_SIZE __SIZE_K(96) | ||
#elif defined(CONFIG_SOC_STM32L476XG) | ||
|
@@ -124,6 +124,9 @@ | |
#elif defined(CONFIG_SOC_STM32L433XC) | ||
#define DT_FLASH_SIZE __SIZE_K(256) | ||
#define DT_SRAM_SIZE __SIZE_K(64) | ||
#elif defined(CONFIG_SOC_DUMMY) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From a quick read, this approach feels kind of ad hoc:
As discussed on IRC, the only reason we are doing C preprocessor checks in our application DTS overlays is specifically to handle the MCUboot partitions, which I don't think belong in DT in the first place. There's also this example here of defining memory sizes based on the SoC. But I don't see why those defines can't be generated from the SoC compatible itself in a clean and generic way -- for example, if the YAML binding language was extended so you could generate defines with the right sizes based on which SoC compatible was specified or chosen (not sure if I'm getting the DT lingo right here, but you get what I mean). So from my perspective, some more generic bindings and solving the MCUboot problem by moving flash partitions to Kconfig defaults would potentially mean there's no need for ifdeffery in the SOC dts overlays at all, and this sort of multi-pass approach wouldn't be needed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I thought that was intended to be ad-hoc, this PR is just to illustrate the discussion we had on IRC. I agree on all the points you list above. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not sure I follow what you are suggesting. Where would we encode the memory & flash sizes? The proper way to handle this is to have different DTS for each SoC variant. So yes, this is specific to SoC handling for flash & sram sizes. We should be avoiding #ifdef in DTS, its not typically the proper way to handle things. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm confused about the purpose of this RFC if the goal is to get rid of ifdef in DTS, as this introduces additional preprocessor logic. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
take a look at #9946 to see how I plan on going forward. The idea was to remove the need for autoconf.h There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That one removes some CONFIG_SOC_xxx ifdeffery by adding SoC-specific dtsi files which the board files have to include now, deleting files like dts/arm/ti/mem.h entirely. This PR, on the other hand, adds additional logic to the very same type of mem.h file. So I don't get how they are related or complementary, sorry; what am I missing? They seem to conflict, actually. I also don't follow how or if 9946 points out a way forward for users who are doing CONFIG_SOC_xxx ifdeffery in their dts overlays today to do the same thing in a future where DT is run before kconfig. |
||
#define DT_FLASH_SIZE __SIZE_K(0) | ||
#define DT_SRAM_SIZE __SIZE_K(0) | ||
#else | ||
#error "Flash, RAM, and CCM sizes not defined for this chip" | ||
#endif | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
#!/usr/bin/env python3 | ||
# | ||
# Copyright (c) 2017, Linaro Limited | ||
# Copyright (c) 2018, Bobby Noelte | ||
# | ||
# SPDX-License-Identifier: Apache-2.0 | ||
# | ||
|
||
# vim: ai:ts=4:sw=4 | ||
|
||
import sys | ||
import pprint | ||
from devicetree import parse_file | ||
|
||
def convert_string_to_label(s): | ||
# Transmute ,-@/ to _ | ||
s = s.replace("-", "_") | ||
s = s.replace(",", "_") | ||
s = s.replace("@", "_") | ||
s = s.replace("/", "_") | ||
# Uppercase the string | ||
s = s.upper() | ||
return s | ||
|
||
def main(args): | ||
if len(args) == 1: | ||
print('Usage: %s filename.dts' % args[0]) | ||
return 1 | ||
|
||
with open(args[1], "r") as fd: | ||
dts = parse_file(fd) | ||
root_compat = dts['/']['props']['compatible'] | ||
soc_compat = dts['/']['children']['soc']['props']['compatible'] | ||
|
||
if not isinstance(soc_compat, list): | ||
soc_compat = [soc_compat] | ||
|
||
if not isinstance(root_compat, list): | ||
root_compat = [root_compat] | ||
|
||
for k in root_compat: | ||
if k != 'simple-bus': | ||
sys.stdout.write('-D%s ' % convert_string_to_label(k)) | ||
|
||
for k in soc_compat: | ||
if k != 'simple-bus': | ||
sys.stdout.write('-DSOC_%s ' % convert_string_to_label(k)) | ||
|
||
sys.stdout.write('\n') | ||
sys.stdout.flush() | ||
|
||
return 0 | ||
|
||
if __name__ == '__main__': | ||
sys.exit(main(sys.argv)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have :
Can't we re-use that instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If aim is to add information in boards.dts in order to remove usage of
DT_SRAM_SIZE
andDT_FLASH_SIZE
,can't we just add matching information :
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erwango
You may have a look at the extended flash property extraction to EDTS in 733ecb0 of #5799.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I guess I'll go with the direct route of having stm32f207zg.dtsi and including that in the board.dts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was hoping we could do that in the board and spare the stm32f207zg to avoid multiplication of dtsi file. Can't we ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like done in linux (https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/stm32f429-disco.dts):
So we keep compatibility..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to avoid having boards that use the same SoC having to duplicate that info. While we could do it in the board.dts I think having a SoC specific .dtsi is the cleanest.