Hi Philipp, Am Donnerstag, 28. Februar 2019, 13:46:44 CET schrieb Heiko Stübner: > Am Donnerstag, 28. Februar 2019, 13:36:52 CET schrieb Philipp Tomsich: > > > On 28.02.2019, at 11:50, Heiko Stübner <he...@sntech.de> wrote: > > > > > > Hi David, > > > > > > Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu: > > >> Hi Heinrich and Michael, > > >> > > >> Another thing i see is that I missed a patch, for the 3288 gpio0, its > > >> iomux is special, there is no high 16-bit write-enabled bit. For Tinker > > >> board, it uses I2C0, the current driver will overwrite the I2C0 iomux, > > >> while request the GPIO0A4. It requires a patch: > > >> > > >> http://patchwork.ozlabs.org/patch/1040541/ > > >> <http://patchwork.ozlabs.org/patch/1040541/>> > > > > > > I've also just stumbled onto the issue of recent uboots not booting > > > on rk3288. While your patch seems to have reached patchwork, somehow > > > the u-boot list seems to have lost it - as it's neither in public > > > archives nor in my inbox it seems. > > > > Please note that I had requested changes to that patch during review. > > I’ll ping David again on when he expect to have those changes implemented > > and ready. > > yeah, I saw that in patchwork, but couldn't comment due to the patch > seemingly not having reach the actual u-boot list strangely. > > That patch doesn't seem to help me right now anyway, as I somehow seem > be stuck on mem_malloc_init() hanging when called from initr_malloc() > (board_r.c) and am not yet sure what is going on there > (on u-boot-master from last friday).
This problem seems to be memory-related somehow? My 2GB rk3288-evb comes up fine to the uboot prompt, while my 1GB rk3288-phycore hangs in said mem_malloc_init(). rk3288-evb (2GB): [...] Relocation Offset is: 7ed88000 Relocating to 7ed88000, new gd at 7cd7fed8, sp at 7cd76230 [...] initr_malloc: before mem_malloc_init using memory 0x7cd80000-0x7ed88000 for malloc() initr_malloc: after mem_malloc_init [...] rk3288-phycore (1GB): [...] Relocation Offset is: 3ff7b000 Relocating to 3ff7b000, new gd at 3df72ee0, sp at 3df68f60 [...] initr_malloc: before mem_malloc_init using memory 0x3df73000-0x3ff7b000 for malloc() [HANG] Do you have some tips what I need to poke for this issue? Heiko > > > Applying the patch does not make my board (phycore-rk3288 in this case) > > > get farther though - I'll investigate more. > > > > > > > > > But it looks like we should be having the same issue in the kernel, just > > > never triggered it, as the gpio0 are of more esotheric uses normally. > > > > > > Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone > > > wouldn't be enough and use that for iomux, pull and drv, similar to > > > what we do for the pull/drv register source already. > > > > > > That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT > > > and PULL_TYPE_WRITABLE_32BIT . > > > > > > > > > Heiko > > > > > >> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道: > > >>> On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote: > > >>>> Hi > > >>>> > > >>>> [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space > > >>>> after > > >>>> relocation > > >>>> > > >>>> Can you check it if you have the same problem? > > >>> > > >>> Applying all the changes causes SPL not to start. > > >>> > > >>> CONFIG_SYS_MALLOC_F_LEN=0x4000 > > >>> does not solve the problem. > > >>> > > >>> Best regards > > >>> > > >>> Heinrich > > >>> > > >>>> Michael > > >>>> > > >>>> > > >>>> On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt > > >>>> <xypron.g...@gmx.de > > >>>> > > >>>> <mailto:xypron.g...@gmx.de> wrote: > > >>>> On 2/17/19 9:19 AM, David Wu wrote: > > >>>>> Hi Henrich, > > >>>>> > > >>>>> 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道: > > >>>>>> On 2/13/19 11:56 AM, Philipp Tomsich wrote: > > >>>> <snip> > > >>>>>> > > >>>>>> Hello David, hello Philipp, > > >>>>>> > > >>>>>> what are your ideas to reduce the SPL size to under 0x7800 again? > > >>>>>> Or will you move all rk3288 boards to TPL like > > >>>>>> TARGET_VYASA_RK3288? > > >>>>> > > >>>>> CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can > > >>>>> make > > >>>>> spl boot. As the Tinker does not use the i2c to read the MAC > > >>>>> address > > >>>>> from eeprom at the SPL stage, which is at uboot. > > >>>>> > > >>>> Hello David, > > >>>> > > >>>> the SPL image size now just fits: > > >>>> Image Type: Rockchip RK32 (SD/MMC) boot image > > >>>> Data Size: 30720 bytes > > >>>> > > >>>> SPL is successful. But MMC is failing in main U-Boot: > > >>>> > > >>>> ``` > > >>>> U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 > > >>>> +0100) > > >>>> Returning to boot ROM... > > >>>> > > >>>> > > >>>> U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 > > >>>> +0100) > > >>>> > > >>>> Model: Tinker-RK3288 > > >>>> DRAM: 2 GiB > > >>>> MMC: dwmmc@ff0c0000: 1 > > >>>> Loading Environment from MMC... > > >>>> ``` > > >>>> > > >>>> No further output here. > > >>>> > > >>>> With some debug output enabled: > > >>>> > > >>>> ``` > > >>>> U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - > > >>>> 13:05:10 > > >>>> +0100) > > >>>> Returning to boot ROM... > > >>>> mmc_bind: alias ret=0, devnum=1 > > >>>> env_init: Environment MMC init done (ret=-2) > > >>>> > > >>>> > > >>>> U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - > > >>>> 13:05:10 > > >>>> +0100) > > >>>> > > >>>> Model: Tinker-RK3288 > > >>>> DRAM: 2 GiB > > >>>> mmc_bind: alias ret=0, devnum=1 > > >>>> MMC: dwmmc@ff0c0000: 1 > > >>>> Loading Environment from MMC... > > >>>> ``` > > >>>> > > >>>> Any suggestion how to proceed? > > >>>> > > >>>> CC: Jaehoon. > > >>>> > > >>>> Best regards > > >>>> > > >>>> Heinrich > > >> > > >> _______________________________________________ > > >> U-Boot mailing list > > >> U-Boot@lists.denx.de <mailto:U-Boot@lists.denx.de> > > >> https://lists.denx.de/listinfo/u-boot > > >> <https://lists.denx.de/listinfo/u-boot>> > > > > > > _______________________________________________ > > > U-Boot mailing list > > > U-Boot@lists.denx.de <mailto:U-Boot@lists.denx.de> > > > https://lists.denx.de/listinfo/u-boot > > > <https://lists.denx.de/listinfo/u-boot> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot