On Wed, 2 Jan 2019 15:14:22 +0100 Marek Vasut <ma...@denx.de> wrote: > On 1/2/19 9:26 AM, Lukasz Majewski wrote: > > Hi Marek, > > > >> On 1/2/19 12:37 AM, Lukasz Majewski wrote: > >>> This commit is necessary to be able to re-use the pinctrl code in > >>> early SPL to properly configure pins. > >>> > >>> The problem is that those "static" structures are placed in the > >>> SDRAM area, which corresponds to u-boot proper (not even SPL). > >>> Hence, when one wants to configure pins before relocation via > >>> DTS/DM, the board hangs (imx6q SoC powered one) as only OCRAM area > >>> is available (0x009xxxxx). > >>> > >>> It is also safe to use calloc in this case, as the early SPL code > >>> provides it - either full or trimmed version. The allocated memory > >>> is also correct in respect to the memory area in which the SoC is > >>> currently running (OCRAM vs. SDRAM). > >> > >> You should be able to access static data in early environment, many > >> other drivers have no problem with it. > > > > Have you used pinctrl IMX6Q driver with early DM at SPL? > > > >> I believe there is some more > >> fundamental problem that needs to be fixed, > > > > With the current code - which was not used in OCRAM only available > > memory - the statics are placed in the SDRAM area (0x178x xxxx). > > > > Instead of changing linker script (and validate it for all drivers > > and boards for SPL and u-boot proper) - the code has been rewritten > > to use malloc (which is available in the early code - either full > > blown or simple version). > > > >> hacking around it like > >> this is just hiding the real issue. > > > > The real issue is that IMX6Q uses SDRAM memory for statics/globals > > from the very beginning. > Fix it ? What you're implying here is that rodata (preinitialized > static variables) are misplaced. >
The not initialized (as going to be zeroed)
static struct imx_pinctrl_soc_info imx6_pinctrl_soc_info;
goes to bss section, which is located in SDRAM (not available yet).
.bss.imx6_pinctrl_soc_info
0x0000000018200050 0x10 drivers/built-in.o
The other structs in this file, as they have assigned values, are placed
correctly in data (OCRAM area).
I could add __attribute__((section("data"))) in front of this
definition, but this may be a problematic for u-boot proper where this
code is reused (and correctly this data is placed in bss).
Hence, the idea to use calloc explicitly - and with it the correct
(available in the moment) memory is provided.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp8LVMI2a_01.pgp
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
