Hi Heinrich, I've integrated this in the use case section of the Techinical Report <https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0XmRk0/edit?usp=sharing> (anyone with the link can comment).
BTW, I missed to publish an agenda for this week's call: I'd like we review the Techinical Report <https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0XmRk0/edit?usp=sharing> outline and possibly name some editors on sections. Cheers FF On Mon, 8 Jun 2020 at 20:34, Heinrich Schuchardt <[email protected]> wrote: > > Hello Francois, > > in our last meeting you suggested to investigate deeper what meaning > modularization in device trees could mean. > > One example I have seen is the definition of memory mappings for PCIe. > > If for you example you look in the device tree of the Raspberry Pi 4 you > can find that there is an entry: > > pcie@7d500000 { > ranges = < > 0x2000000 0x00 0xf8000000 0x06 0x00 0x00 0x4000000>; > }; > > The ranges property defines the mapping > MEM 0x600000000..0x603ffffff -> 0xf8000000 > and thereby the address and size of the memory windows used for > communication. > > On some boards e.g. the MacchitoBin you have multiple platform devices > each with its own ranges definitions. Here are the values in May 2019: > > pcie@f2600000 { > ranges = < > 0x81000000 0x0 0xf9000000 0x0 0xf9000000 0x0 0x10000 > 0x82000000 0x0 0xf6000000 0x0 0xf6000000 0x0 0xf00000>; > } > pcie@f2620000 { > ranges = < > 0x81000000 0x0 0xf9010000 0x0 0xf9010000 0x0 0x10000 > 0x82000000 0x0 0xf7000000 0x0 0xf7000000 0x0 0xf00000>; > } > pcie@f2640000 { > ranges = < > 0x81000000 0x0 0xf9020000 0x0 0xf9020000 0x0 0x10000 > 0x82000000 0x0 0xf8000000 0x0 0xf8000000 0x0 0xf00000>; > } > > On my MacchitoBin the GPU card was not usable because the memory window > was too small to create the required BARs. Changing the window size and > location solved the problem, commit d3446b266a8c ("arm64: dts: marvell: > mcbin: enlarge PCI memory window"). > > The problem with the current way in qhich PCI devices are declared is > that they do not indicate requirements and capabilities and let the > software figure out a good mapping. But instead fixed mappings are > hard-coded into the device-tree. > > So for me this would be one element of DT modularization: > > The description of a device should provide capabilities and requirements > and avoid fixed software settings. > > Best regards > > Heinrich > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
