[U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

["Heiko Stübner" <heiko@sntech.de>]

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 <heiko@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.glpk@gmx.de
> > >>>> 
> > >>>> <mailto:xypron.glpk@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 at 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 at ff0c0000: 1
> > >>>>     Loading Environment from MMC...
> > >>>>     ```
> > >>>>     
> > >>>>     Any suggestion how to proceed?
> > >>>>     
> > >>>>     CC: Jaehoon.
> > >>>>     
> > >>>>     Best regards
> > >>>>     
> > >>>>     Heinrich
> > >> 
> > >> _______________________________________________
> > >> U-Boot mailing list
> > >> U-Boot at 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 at lists.denx.de <mailto:U-Boot@lists.denx.de>
> > > https://lists.denx.de/listinfo/u-boot
> > > <https://lists.denx.de/listinfo/u-boot>