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

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

[Heinrich Schuchardt]

Hello Simon, hello Philipp,

since patch

Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip
e5fd39c886485e3dec77f4438a6e364c2987cf5f

booting on the Tinker Board (tinker-rk3288_defconfig) is broken.

There is not even any UART output from SPL.

Best regards

Heinrich

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

[Philipp Tomsich]

Heinrich,

My guess is that this is fallout from David Wu’s new pinctrl driver
(which has really been the bulk of changes in this cycle).  I can’t
test or debug on the rk3288 due to a lack of hardware.

I did add fix some issues for the RK3399 (and have more to submit).
The expectation is that I'll need to add further fixes for the RK3368
(the second platform I can test on) in later RCs.

Thanks,
Philipp.

> On 09.02.2019, at 13:12, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> 
> Hello Simon, hello Philipp,
> 
> since patch
> 
> Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip
> e5fd39c886485e3dec77f4438a6e364c2987cf5f
> 
> booting on the Tinker Board (tinker-rk3288_defconfig) is broken.
> 
> There is not even any UART output from SPL.
> 
> Best regards
> 
> Heinrich

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

[Philipp Tomsich]

> On 09.02.2019, at 16:08, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
> 
> Heinrich,
> 
> My guess is that this is fallout from David Wu’s new pinctrl driver
> (which has really been the bulk of changes in this cycle).  I can’t
> test or debug on the rk3288 due to a lack of hardware.

If you want to start digging, that the changes in

> commit 08c817c39908f9d120df1e4c90ddad4a11fc3891
> Author: David Wu <david.wu@rock-chips.com>
> Date:   Wed Jan 2 20:51:00 2019 +0800
> 
>     ARM: rockchip: Remove the pinctrl request at rk3288-board-spl
>     
>     If we use the new pinctrl driver, the pinctrl setup will be done
>     by device probe. Remove the pinctrl setup at rk3288-board-spl.
>     
>     Signed-off-by: David Wu <david.wu@rock-chips.com>
>     Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
>     Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>


look like they have the potential to break everything, including the
UART pinctrl.

Thanks,
Philipp.,

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

[Heinrich Schuchardt]

On 2/9/19 4:24 PM, Philipp Tomsich wrote:
> 
> 
>> On 09.02.2019, at 16:08, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
>>
>> Heinrich,
>>
>> My guess is that this is fallout from David Wu’s new pinctrl driver
>> (which has really been the bulk of changes in this cycle).  I can’t
>> test or debug on the rk3288 due to a lack of hardware.
> 
> If you want to start digging, that the changes in
> 
>> commit 08c817c39908f9d120df1e4c90ddad4a11fc3891
>> Author: David Wu <david.wu@rock-chips.com>
>> Date:   Wed Jan 2 20:51:00 2019 +0800
>>
>>     ARM: rockchip: Remove the pinctrl request at rk3288-board-spl
>>     
>>     If we use the new pinctrl driver, the pinctrl setup will be done
>>     by device probe. Remove the pinctrl setup at rk3288-board-spl.
>>     
>>     Signed-off-by: David Wu <david.wu@rock-chips.com>
>>     Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
>>     Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
> 
> 
> look like they have the potential to break everything, including the
> UART pinctrl.
> 
> Thanks,
> Philipp.,
> 
Hello Philipp,

I would not know how to analyze the bug if there isn't even a console.

If David or you send me a git branch to compile I will test it.

Has any of the rk3288 boards been tested before merging?

I think we should keep Simon in CC as he is one of the ROCKCHIP maintainers.

Best regards

Heinrich

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

[Philipp Tomsich]

> On 09.02.2019, at 17:39, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> 
> On 2/9/19 4:24 PM, Philipp Tomsich wrote:
>> 
>> 
>>> On 09.02.2019, at 16:08, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
>>> 
>>> Heinrich,
>>> 
>>> My guess is that this is fallout from David Wu’s new pinctrl driver
>>> (which has really been the bulk of changes in this cycle).  I can’t
>>> test or debug on the rk3288 due to a lack of hardware.
>> 
>> If you want to start digging, that the changes in
>> 
>>> commit 08c817c39908f9d120df1e4c90ddad4a11fc3891
>>> Author: David Wu <david.wu@rock-chips.com>
>>> Date:   Wed Jan 2 20:51:00 2019 +0800
>>> 
>>>    ARM: rockchip: Remove the pinctrl request at rk3288-board-spl
>>> 
>>>    If we use the new pinctrl driver, the pinctrl setup will be done
>>>    by device probe. Remove the pinctrl setup at rk3288-board-spl.
>>> 
>>>    Signed-off-by: David Wu <david.wu@rock-chips.com>
>>>    Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
>>>    Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
>> 
>> 
>> look like they have the potential to break everything, including the
>> UART pinctrl.
>> 
>> Thanks,
>> Philipp.,
>> 
> Hello Philipp,
> 
> I would not know how to analyze the bug if there isn't even a console.
> If David or you send me a git branch to compile I will test it.

We’ll have to wait for David to come back from CNY, apparently.

> Has any of the rk3288 boards been tested before merging?

I would assume so, as this patchset is coming from Rockchips and Kever
gave his Reviewed-by…

That said, I have been fighting issues from this patchset when trying to read
from devices on the i2c0 bus on a RK3399—which had me add a “simple”
pinctrl device again, as pulling all the dependencies into the SPL is a pain.

Unfortunately, in this merge I had to make a judgement call between insisting
on code-quality and getting the full pinctrl-driver merged.  With this release
cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
wrinkles...

> I think we should keep Simon in CC as he is one of the ROCKCHIP maintainers.

I didn’t intentionally drop him. It was either clumsy fingers or Reply-All not
replying to all.

Cheers,
Philipp.

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

[David Wu]

Hi Philipp,

在 2019/2/10 上午2:24, Philipp Tomsich 写道:
> That said, I have been fighting issues from this patchset when trying to read
> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> 

I think you can also add the simple ops if necessary. Full pinctrl
should only be used at the U-boot stage, or the SPL stage where the TPL 
is available.

For most boards about 3288, there is no need to enable pinctrl at SPL
stage, such as Tinker board.


> Unfortunately, in this merge I had to make a judgement call between insisting
> on code-quality and getting the full pinctrl-driver merged.  With this release
> cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
> wrinkles...

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

[Philipp Tomsich]

> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>> That said, I have been fighting issues from this patchset when trying to read
>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> 
> I think you can also add the simple ops if necessary. Full pinctrl
> should only be used at the U-boot stage, or the SPL stage where the TPL is available.

I started on this and will submit it with the follow-on changes that depend on this, as
I don’t want to pull in the ~10k of extra size.

There’s a number of failure modes in the SPL/TPL path from missing DTB nodes (as
one would need to add pre-reloc tags to all pinctrl and dependent nodes).

> For most boards about 3288, there is no need to enable pinctrl at SPL
> stage, such as Tinker board.
> 
> 
>> Unfortunately, in this merge I had to make a judgement call between insisting
>> on code-quality and getting the full pinctrl-driver merged.  With this release
>> cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
>> wrinkles...
> 
> 

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

[David Wu]

Hi Philipp,

在 2019/2/12 下午9:53, Philipp Tomsich 写道:
> 
> 
>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>
>> Hi Philipp,
>>
>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>> That said, I have been fighting issues from this patchset when trying to read
>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>
>> I think you can also add the simple ops if necessary. Full pinctrl
>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
> 
> I started on this and will submit it with the follow-on changes that depend on this, as
> I don’t want to pull in the ~10k of extra size.

10k is a bit exaggerated, I think I can split some common functions
into each Soc chip file, can reduce some size.

For the simple ops, do you feel like get prop from "pinctrl-0", and then
the pinctrl process is similar to what it is now.

> 
> There’s a number of failure modes in the SPL/TPL path from missing DTB nodes (as
> one would need to add pre-reloc tags to all pinctrl and dependent nodes).
> 
>> For most boards about 3288, there is no need to enable pinctrl at SPL
>> stage, such as Tinker board.
>>
>>
>>> Unfortunately, in this merge I had to make a judgement call between insisting
>>> on code-quality and getting the full pinctrl-driver merged.  With this release
>>> cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
>>> wrinkles...
>>
>>
> 
> 
> 

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

[Philipp Tomsich]

David,

> On 13.02.2019, at 11:28, David Wu <david.wu@rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> 在 2019/2/12 下午9:53, Philipp Tomsich 写道:
>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>> 
>>> Hi Philipp,
>>> 
>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>> That said, I have been fighting issues from this patchset when trying to read
>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>> 
>>> I think you can also add the simple ops if necessary. Full pinctrl
>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>> I started on this and will submit it with the follow-on changes that depend on this, as
>> I don’t want to pull in the ~10k of extra size.
> 
> 10k is a bit exaggerated, I think I can split some common functions
> into each Soc chip file, can reduce some size.

The 10k comes from a direct comparison on our RK3399-Q7, after pulling in all
the required DTS nodes and properties vs. a minimal simple pinctrl for I2C only
(which is ~ 100 bytes of code).

> For the simple ops, do you feel like get prop from "pinctrl-0", and then
> the pinctrl process is similar to what it is now.
> 
>> There’s a number of failure modes in the SPL/TPL path from missing DTB nodes (as
>> one would need to add pre-reloc tags to all pinctrl and dependent nodes).
>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>> stage, such as Tinker board.
>>> 
>>> 
>>>> Unfortunately, in this merge I had to make a judgement call between insisting
>>>> on code-quality and getting the full pinctrl-driver merged.  With this release
>>>> cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
>>>> wrinkles...
>>> 
>>> 
> 
> 

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

[David Wu]

Hi Philipp,

在 2019/2/13 下午6:30, Philipp Tomsich 写道:
> The 10k comes from a direct comparison on our RK3399-Q7, after pulling in all
> the required DTS nodes and properties vs. a minimal simple pinctrl for I2C only
> (which is ~ 100 bytes of code).

So according to your mind, do not use DTS at the SPL stage, still follow
the original way, use the periph id?

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

[Philipp Tomsich]

> On 13.02.2019, at 11:42, David Wu <david.wu@rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> 在 2019/2/13 下午6:30, Philipp Tomsich 写道:
>> The 10k comes from a direct comparison on our RK3399-Q7, after pulling in all
>> the required DTS nodes and properties vs. a minimal simple pinctrl for I2C only
>> (which is ~ 100 bytes of code).
> 
> So according to your mind, do not use DTS at the SPL stage, still follow
> the original way, use the periph id?

Yes. And the periph-id uses the base-addr (instead of the interrupt number), so I
have simpler code (i.e. dev_read_addr, which will just deref the node and get the
addr) instead of having to go to the tree again.

I’ll prepare the patch (need to check if additional work is needed for PWM) and
send this separately.

Thanks,
Philipp.

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

[Philipp Tomsich]

> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>> That said, I have been fighting issues from this patchset when trying to read
>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> 
> I think you can also add the simple ops if necessary. Full pinctrl
> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
> 
> For most boards about 3288, there is no need to enable pinctrl at SPL
> stage, such as Tinker board.

Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
the RK3288? If not, please submit a patch.

>> Unfortunately, in this merge I had to make a judgement call between insisting
>> on code-quality and getting the full pinctrl-driver merged.  With this release
>> cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
>> wrinkles...
> 
> 

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

[David Wu]

Hi Philipp,

在 2019/2/12 下午9:54, Philipp Tomsich 写道:
> 
> 
>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>
>> Hi Philipp,
>>
>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>> That said, I have been fighting issues from this patchset when trying to read
>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>
>> I think you can also add the simple ops if necessary. Full pinctrl
>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>
>> For most boards about 3288, there is no need to enable pinctrl at SPL
>> stage, such as Tinker board.
> 
> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
> the RK3288? If not, please submit a patch.

It is correct, 32KB.

> 
>>> Unfortunately, in this merge I had to make a judgement call between insisting
>>> on code-quality and getting the full pinctrl-driver merged.  With this release
>>> cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
>>> wrinkles...
>>
>>
> 
> 
> 
> 

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

[Philipp Tomsich]

> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>> 
>>> Hi Philipp,
>>> 
>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>> That said, I have been fighting issues from this patchset when trying to read
>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>> 
>>> I think you can also add the simple ops if necessary. Full pinctrl
>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>> 
>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>> stage, such as Tinker board.
>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>> the RK3288? If not, please submit a patch.
> 
> It is correct, 32KB.

Interesting...
I wonder why the build did not fail then, if SPL became too big.

Anyway, let’s file this under “things to revisit, if the problem recurs”.

Thanks,
Philipp.

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

[David Wu]

在 2019/2/13 下午6:13, Philipp Tomsich 写道:
> 
> 
>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>
>> Hi Philipp,
>>
>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>
>>>> Hi Philipp,
>>>>
>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>
>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>
>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>> stage, such as Tinker board.
>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>> the RK3288? If not, please submit a patch.
>>
>> It is correct, 32KB.
> 
> Interesting...
> I wonder why the build did not fail then, if SPL became too big.

Popmetal is okay, the SPL is too big for Tinker, i didn't test Tinker.

> 
> Anyway, let’s file this under “things to revisit, if the problem recurs”.
> 
> Thanks,
> Philipp.
> 
> 
> 
> 
> 

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

[Philipp Tomsich]

> On 13.02.2019, at 11:33, David Wu <david.wu@rock-chips.com> wrote:
> 
> 
> 
> 在 2019/2/13 下午6:13, Philipp Tomsich 写道:
>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>> 
>>> Hi Philipp,
>>> 
>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>> 
>>>>> Hi Philipp,
>>>>> 
>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>> 
>>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>> 
>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>>> stage, such as Tinker board.
>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>>> the RK3288? If not, please submit a patch.
>>> 
>>> It is correct, 32KB.
>> Interesting...
>> I wonder why the build did not fail then, if SPL became too big.
> 
> Popmetal is okay, the SPL is too big for Tinker, i didn't test Tinker.

If it is too big for Tinker: does the build fail or silently ignore the error?

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

[David Wu]

Hi philipp,

在 2019/2/13 下午6:47, Philipp Tomsich 写道:
> 
> 
>> On 13.02.2019, at 11:33, David Wu <david.wu@rock-chips.com> wrote:
>>
>>
>>
>> 在 2019/2/13 下午6:13, Philipp Tomsich 写道:
>>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>>>
>>>> Hi Philipp,
>>>>
>>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>>>
>>>>>> Hi Philipp,
>>>>>>
>>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>>>
>>>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>>>
>>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>>>> stage, such as Tinker board.
>>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>>>> the RK3288? If not, please submit a patch.
>>>>
>>>> It is correct, 32KB.
>>> Interesting...
>>> I wonder why the build did not fail then, if SPL became too big.
>>
>> Popmetal is okay, the SPL is too big for Tinker, i didn't test Tinker.
> 
> If it is too big for Tinker: does the build fail or silently ignore the error?
build is okay, mkimage can get the error, i just build, not to mkimage 
for Tinker.
> 

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

[Philipp Tomsich]

> On 13.02.2019, at 11:52, David Wu <david.wu@rock-chips.com> wrote:
> 
> Hi philipp,
> 
> 在 2019/2/13 下午6:47, Philipp Tomsich 写道:
>>> On 13.02.2019, at 11:33, David Wu <david.wu@rock-chips.com> wrote:
>>> 
>>> 
>>> 
>>> 在 2019/2/13 下午6:13, Philipp Tomsich 写道:
>>>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>>>> 
>>>>> Hi Philipp,
>>>>> 
>>>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>>>> 
>>>>>>> Hi Philipp,
>>>>>>> 
>>>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>>>> 
>>>>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>>>> 
>>>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>>>>> stage, such as Tinker board.
>>>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>>>>> the RK3288? If not, please submit a patch.
>>>>> 
>>>>> It is correct, 32KB.
>>>> Interesting...
>>>> I wonder why the build did not fail then, if SPL became too big.
>>> 
>>> Popmetal is okay, the SPL is too big for Tinker, i didn't test Tinker.
>> If it is too big for Tinker: does the build fail or silently ignore the error?
> build is okay, mkimage can get the error, i just build, not to mkimage for Tinker.

This is more than enough (mkimage is part of the build for me!)
I was just wondering why Heinrich ran into this problem and didn’t 
see a build error (even at the mkimage stage).

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

[Heinrich Schuchardt]

On 2/13/19 11:56 AM, Philipp Tomsich wrote:
> 
> 
>> On 13.02.2019, at 11:52, David Wu <david.wu@rock-chips.com> wrote:
>>
>> Hi philipp,
>>
>> 在 2019/2/13 下午6:47, Philipp Tomsich 写道:
>>>> On 13.02.2019, at 11:33, David Wu <david.wu@rock-chips.com> wrote:
>>>>
>>>>
>>>>
>>>> 在 2019/2/13 下午6:13, Philipp Tomsich 写道:
>>>>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>>>>>
>>>>>> Hi Philipp,
>>>>>>
>>>>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>>>>>
>>>>>>>> Hi Philipp,
>>>>>>>>
>>>>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>>>>>
>>>>>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>>>>>
>>>>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>>>>>> stage, such as Tinker board.
>>>>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>>>>>> the RK3288? If not, please submit a patch.
>>>>>>
>>>>>> It is correct, 32KB.
>>>>> Interesting...
>>>>> I wonder why the build did not fail then, if SPL became too big.
>>>>
>>>> Popmetal is okay, the SPL is too big for Tinker, i didn't test Tinker.
>>> If it is too big for Tinker: does the build fail or silently ignore the error?
>> build is okay, mkimage can get the error, i just build, not to mkimage for Tinker.
> 
> This is more than enough (mkimage is part of the build for me!)
> I was just wondering why Heinrich ran into this problem and didn’t 
> see a build error (even at the mkimage stage).
> 
> 

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?

Best regards

Heinrich

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

[David Wu]

Hi Henrich,

在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
>>
>>
>>> On 13.02.2019, at 11:52, David Wu <david.wu@rock-chips.com> wrote:
>>>
>>> Hi philipp,
>>>
>>> 在 2019/2/13 下午6:47, Philipp Tomsich 写道:
>>>>> On 13.02.2019, at 11:33, David Wu <david.wu@rock-chips.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> 在 2019/2/13 下午6:13, Philipp Tomsich 写道:
>>>>>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>>>>>>
>>>>>>> Hi Philipp,
>>>>>>>
>>>>>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>>>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Philipp,
>>>>>>>>>
>>>>>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>>>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>>>>>>
>>>>>>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>>>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>>>>>>
>>>>>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>>>>>>> stage, such as Tinker board.
>>>>>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>>>>>>> the RK3288? If not, please submit a patch.
>>>>>>>
>>>>>>> It is correct, 32KB.
>>>>>> Interesting...
>>>>>> I wonder why the build did not fail then, if SPL became too big.
>>>>>
>>>>> Popmetal is okay, the SPL is too big for Tinker, i didn't test Tinker.
>>>> If it is too big for Tinker: does the build fail or silently ignore the error?
>>> build is okay, mkimage can get the error, i just build, not to mkimage for Tinker.
>>
>> This is more than enough (mkimage is part of the build for me!)
>> I was just wondering why Heinrich ran into this problem and didn’t
>> see a build error (even at the mkimage stage).
>>
>>
> 
> 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.

> 
> Best regards
> 
> Heinrich
> 
> 

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

[Heinrich Schuchardt]

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] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

[Michael Nazzareno Trimarchi]

Hi

[U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space after
relocation

Can you check it if you have the same problem?

Michael


On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt <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
> https://lists.denx.de/listinfo/u-boot
>

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

[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] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

[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/

在 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] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

[Heiko Stübner]

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/

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.

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
> https://lists.denx.de/listinfo/u-boot

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

[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.

> 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>

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

[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).




> > 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>

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

[Heiko Stübner]

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>

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

[David Wu]

Hi Heiko,

在 2019/2/28 下午9:29, Heiko Stübner 写道:
> 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().
> 

Is this issue introduced by the pinctrl patch?

> 
> 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>
> 
> 
> 
> 
> 
> 
> 

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

[David Wu]

Hi Philipp,

在 2019/2/28 下午8:36, Philipp Tomsich 写道:
>
>
>> On 28.02.2019, at 11:50, Heiko Stübner <heiko@sntech.de 
>> <mailto: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/
>>
>> 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.

Yes,  I am preparing this part of the modification for your request, and 
after the
change. need to verify the more chips.  Just recently more things are on 
going.

>
>> 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 at gmx.de <mailto: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
>>
>>
>>
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
>> https://lists.denx.de/listinfo/u-boot
>

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

[Philipp Tomsich]

> On 01.03.2019, at 13:29, David Wu <david.wu@rock-chips.com> wrote:
> 
> Hi Philipp,
> 在 2019/2/28 下午8:36, Philipp Tomsich 写道:
>> 
>> 
>>> On 28.02.2019, at 11:50, Heiko Stübner <heiko at sntech.de <mailto: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.
> Yes,  I am preparing this part of the modification for your request, and after the
> change. need to verify the more chips.  Just recently more things are on going.
> 
Thanks for responding today… I had the task to ping you on my list for later today
& you saved me the work ;-)

>> 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 at gmx.de <mailto:xypron.glpk@gmx.de>
>>>>>> 
>>>>>> <mailto:xypron.glpk at 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>

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

[Tom Rini]

On Wed, Feb 13, 2019 at 11:13:19AM +0100, Philipp Tomsich wrote:
> 
> 
> > On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
> > 
> > Hi Philipp,
> > 
> > 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
> >>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
> >>> 
> >>> Hi Philipp,
> >>> 
> >>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
> >>>> That said, I have been fighting issues from this patchset when trying to read
> >>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
> >>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> >>> 
> >>> I think you can also add the simple ops if necessary. Full pinctrl
> >>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
> >>> 
> >>> For most boards about 3288, there is no need to enable pinctrl at SPL
> >>> stage, such as Tinker board.
> >> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
> >> the RK3288? If not, please submit a patch.
> > 
> > It is correct, 32KB.
> 
> Interesting...
> I wonder why the build did not fail then, if SPL became too big.

This is probably the "we need BOARD_SIZE_CHECK used more widely too"
issue that's come up in other threads.  The linker-only check does not
catch the CONFIG_OF_SEPARATE dtb exceeds limit problem as it's
post-link.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190213/1e604583/attachment.sig>

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

[Heinrich Schuchardt]

On 2/13/19 1:25 PM, Tom Rini wrote:
> On Wed, Feb 13, 2019 at 11:13:19AM +0100, Philipp Tomsich wrote:
>>
>>
>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>>
>>> Hi Philipp,
>>>
>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>>
>>>>> Hi Philipp,
>>>>>
>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>>
>>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>>
>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>>> stage, such as Tinker board.
>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>>> the RK3288? If not, please submit a patch.
>>>
>>> It is correct, 32KB.
>>
>> Interesting...
>> I wonder why the build did not fail then, if SPL became too big.
> 
> This is probably the "we need BOARD_SIZE_CHECK used more widely too"
> issue that's come up in other threads.  The linker-only check does not
> catch the CONFIG_OF_SEPARATE dtb exceeds limit problem as it's
> post-link.
> 

This is the error message I currently get for U-Boot 2019.04 when
building for the Tinker Board:

mkdir -p foo/usr/lib/u-boot/tinker/
denx/tools/mkimage -n rk3288 -T rksd -d denx/spl/u-boot-spl-dtb.bin \
  foo/usr/lib/u-boot/tinker/u-boot.img
Warning: SPL image is too large (size 0x8800) and will not boot
Error: image verification failed
cat denx/u-boot-dtb.bin >> foo/usr/lib/u-boot/tinker/u-boot.img
cp sd_fusing.sh foo/usr/lib/u-boot/tinker/

@Tom
Shouldn't the mkimage step be included in Travis CI testing?

Best regards

Heinrich

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

[Tom Rini]

On Wed, Feb 13, 2019 at 02:16:12PM +0100, Heinrich Schuchardt wrote:
> 
> 
> On 2/13/19 1:25 PM, Tom Rini wrote:
> > On Wed, Feb 13, 2019 at 11:13:19AM +0100, Philipp Tomsich wrote:
> >>
> >>
> >>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
> >>>
> >>> Hi Philipp,
> >>>
> >>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
> >>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
> >>>>>
> >>>>> Hi Philipp,
> >>>>>
> >>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
> >>>>>> That said, I have been fighting issues from this patchset when trying to read
> >>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
> >>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> >>>>>
> >>>>> I think you can also add the simple ops if necessary. Full pinctrl
> >>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
> >>>>>
> >>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
> >>>>> stage, such as Tinker board.
> >>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
> >>>> the RK3288? If not, please submit a patch.
> >>>
> >>> It is correct, 32KB.
> >>
> >> Interesting...
> >> I wonder why the build did not fail then, if SPL became too big.
> > 
> > This is probably the "we need BOARD_SIZE_CHECK used more widely too"
> > issue that's come up in other threads.  The linker-only check does not
> > catch the CONFIG_OF_SEPARATE dtb exceeds limit problem as it's
> > post-link.
> > 
> 
> This is the error message I currently get for U-Boot 2019.04 when
> building for the Tinker Board:
> 
> mkdir -p foo/usr/lib/u-boot/tinker/
> denx/tools/mkimage -n rk3288 -T rksd -d denx/spl/u-boot-spl-dtb.bin \
>   foo/usr/lib/u-boot/tinker/u-boot.img
> Warning: SPL image is too large (size 0x8800) and will not boot
> Error: image verification failed
> cat denx/u-boot-dtb.bin >> foo/usr/lib/u-boot/tinker/u-boot.img
> cp sd_fusing.sh foo/usr/lib/u-boot/tinker/
> 
> @Tom
> Shouldn't the mkimage step be included in Travis CI testing?

No, mkimage fails for almost every aarch64 target as we don't include
ATF or the other blobs required to make things bootable.
BOARD_SIZE_CHECK is where we can confirm that the U-Boot binary isn't
too large.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190213/58d8447f/attachment.sig>

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

[Heinrich Schuchardt]

On 2/13/19 2:24 PM, Tom Rini wrote:
> On Wed, Feb 13, 2019 at 02:16:12PM +0100, Heinrich Schuchardt wrote:
>>
>>
>> On 2/13/19 1:25 PM, Tom Rini wrote:
>>> On Wed, Feb 13, 2019 at 11:13:19AM +0100, Philipp Tomsich wrote:
>>>>
>>>>
>>>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
>>>>>
>>>>> Hi Philipp,
>>>>>
>>>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
>>>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
>>>>>>>
>>>>>>> Hi Philipp,
>>>>>>>
>>>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>>>>>>>> That said, I have been fighting issues from this patchset when trying to read
>>>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>>>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
>>>>>>>
>>>>>>> I think you can also add the simple ops if necessary. Full pinctrl
>>>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
>>>>>>>
>>>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
>>>>>>> stage, such as Tinker board.
>>>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
>>>>>> the RK3288? If not, please submit a patch.
>>>>>
>>>>> It is correct, 32KB.
>>>>
>>>> Interesting...
>>>> I wonder why the build did not fail then, if SPL became too big.
>>>
>>> This is probably the "we need BOARD_SIZE_CHECK used more widely too"
>>> issue that's come up in other threads.  The linker-only check does not
>>> catch the CONFIG_OF_SEPARATE dtb exceeds limit problem as it's
>>> post-link.
>>>
>>
>> This is the error message I currently get for U-Boot 2019.04 when
>> building for the Tinker Board:
>>
>> mkdir -p foo/usr/lib/u-boot/tinker/
>> denx/tools/mkimage -n rk3288 -T rksd -d denx/spl/u-boot-spl-dtb.bin \
>>   foo/usr/lib/u-boot/tinker/u-boot.img
>> Warning: SPL image is too large (size 0x8800) and will not boot
>> Error: image verification failed
>> cat denx/u-boot-dtb.bin >> foo/usr/lib/u-boot/tinker/u-boot.img
>> cp sd_fusing.sh foo/usr/lib/u-boot/tinker/
>>
>> @Tom
>> Shouldn't the mkimage step be included in Travis CI testing?
> 
> No, mkimage fails for almost every aarch64 target as we don't include
> ATF or the other blobs required to make things bootable.
> BOARD_SIZE_CHECK is where we can confirm that the U-Boot binary isn't
> too large.
> 

Hello Tom,

BOARD_SIZE_CHECK seems to be about the U-Boot image not about SPL. I
guess we need to copy this line to rk3288_common.h:

include/configs/rk3188_common.h:31:
#define CONFIG_SPL_MAX_SIZE          (0x8000 - 0x800)

But when I insert this line I get no linker error but the size of
denx/spl/u-boot-spl-dtb.bin is still too big.

Shouldn't count the DTB size be accounted for when doing the
CONFIG_SPL_MAX_SIZE check?

CONFIG_SPL_MAX_SIZE      30720 bytes
spl/u-boot-spl-nodtb.bin 28932 bytes
spl/u-boot-spl.dtb        4096 bytes
spl/u-boot-spl-dtb.bin   32986 bytes

Best regards

Heinrich

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

[Tom Rini]

On Wed, Feb 13, 2019 at 09:13:31PM +0100, Heinrich Schuchardt wrote:
> 
> 
> On 2/13/19 2:24 PM, Tom Rini wrote:
> > On Wed, Feb 13, 2019 at 02:16:12PM +0100, Heinrich Schuchardt wrote:
> >>
> >>
> >> On 2/13/19 1:25 PM, Tom Rini wrote:
> >>> On Wed, Feb 13, 2019 at 11:13:19AM +0100, Philipp Tomsich wrote:
> >>>>
> >>>>
> >>>>> On 13.02.2019, at 11:10, David Wu <david.wu@rock-chips.com> wrote:
> >>>>>
> >>>>> Hi Philipp,
> >>>>>
> >>>>> 在 2019/2/12 下午9:54, Philipp Tomsich 写道:
> >>>>>>> On 12.02.2019, at 13:38, David Wu <david.wu@rock-chips.com> wrote:
> >>>>>>>
> >>>>>>> Hi Philipp,
> >>>>>>>
> >>>>>>> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
> >>>>>>>> That said, I have been fighting issues from this patchset when trying to read
> >>>>>>>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
> >>>>>>>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> >>>>>>>
> >>>>>>> I think you can also add the simple ops if necessary. Full pinctrl
> >>>>>>> should only be used at the U-boot stage, or the SPL stage where the TPL is available.
> >>>>>>>
> >>>>>>> For most boards about 3288, there is no need to enable pinctrl at SPL
> >>>>>>> stage, such as Tinker board.
> >>>>>> Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
> >>>>>> the RK3288? If not, please submit a patch.
> >>>>>
> >>>>> It is correct, 32KB.
> >>>>
> >>>> Interesting...
> >>>> I wonder why the build did not fail then, if SPL became too big.
> >>>
> >>> This is probably the "we need BOARD_SIZE_CHECK used more widely too"
> >>> issue that's come up in other threads.  The linker-only check does not
> >>> catch the CONFIG_OF_SEPARATE dtb exceeds limit problem as it's
> >>> post-link.
> >>>
> >>
> >> This is the error message I currently get for U-Boot 2019.04 when
> >> building for the Tinker Board:
> >>
> >> mkdir -p foo/usr/lib/u-boot/tinker/
> >> denx/tools/mkimage -n rk3288 -T rksd -d denx/spl/u-boot-spl-dtb.bin \
> >>   foo/usr/lib/u-boot/tinker/u-boot.img
> >> Warning: SPL image is too large (size 0x8800) and will not boot
> >> Error: image verification failed
> >> cat denx/u-boot-dtb.bin >> foo/usr/lib/u-boot/tinker/u-boot.img
> >> cp sd_fusing.sh foo/usr/lib/u-boot/tinker/
> >>
> >> @Tom
> >> Shouldn't the mkimage step be included in Travis CI testing?
> > 
> > No, mkimage fails for almost every aarch64 target as we don't include
> > ATF or the other blobs required to make things bootable.
> > BOARD_SIZE_CHECK is where we can confirm that the U-Boot binary isn't
> > too large.
> > 
> 
> Hello Tom,
> 
> BOARD_SIZE_CHECK seems to be about the U-Boot image not about SPL. I

I was possibly being slightly too literal, sorry.  We need to adapt and
use the "check the resulting final binary is OK size-wise" logic to be
available and used everywhere.  Given that we're now at I think 3 or 4
different SoCs running into this same exact problem, we really do need
to.

> guess we need to copy this line to rk3288_common.h:
> 
> include/configs/rk3188_common.h:31:
> #define CONFIG_SPL_MAX_SIZE          (0x8000 - 0x800)
> 
> But when I insert this line I get no linker error but the size of
> denx/spl/u-boot-spl-dtb.bin is still too big.
> 
> Shouldn't count the DTB size be accounted for when doing the
> CONFIG_SPL_MAX_SIZE check?
> 
> CONFIG_SPL_MAX_SIZE      30720 bytes
> spl/u-boot-spl-nodtb.bin 28932 bytes
> spl/u-boot-spl.dtb        4096 bytes
> spl/u-boot-spl-dtb.bin   32986 bytes

SPL_MAX_SIZE is a linker check and as such will not catch post-linking
things, is the problem.  We should however make it not be a linker check
and instead leverage it with the logic behind BOARD_SIZE_CHECK, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190213/278b6c25/attachment.sig>

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

[David Wu]

Hi Heinrich,

在 2019/2/10 上午12:39, Heinrich Schuchardt 写道:
> On 2/9/19 4:24 PM, Philipp Tomsich wrote:
>>
>>
>>> On 09.02.2019, at 16:08, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
>>>
>>> Heinrich,
>>>
>>> My guess is that this is fallout from David Wu’s new pinctrl driver
>>> (which has really been the bulk of changes in this cycle).  I can’t
>>> test or debug on the rk3288 due to a lack of hardware.
>>
>> If you want to start digging, that the changes in
>>
>>> commit 08c817c39908f9d120df1e4c90ddad4a11fc3891
>>> Author: David Wu <david.wu@rock-chips.com>
>>> Date:   Wed Jan 2 20:51:00 2019 +0800
>>>
>>>      ARM: rockchip: Remove the pinctrl request at rk3288-board-spl
>>>      
>>>      If we use the new pinctrl driver, the pinctrl setup will be done
>>>      by device probe. Remove the pinctrl setup at rk3288-board-spl.
>>>      
>>>      Signed-off-by: David Wu <david.wu@rock-chips.com>
>>>      Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
>>>      Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
>>
>>
>> look like they have the potential to break everything, including the
>> UART pinctrl.
>>
>> Thanks,
>> Philipp.,
>>
> Hello Philipp,
> 
> I would not know how to analyze the bug if there isn't even a console.

The reason i see, that is the u-boot-spl-dtb.bin is too large for 
bootrom, while supports full pinctrl at SPL stage.

Compared to the popmetal-rk3288_defconfig, CONFIG_SPL_I2C_SUPPORT is not 
enabled at PopMetal. Remove this config to reduces the spl bin size, 
makes the Tinker board to boot. As the tinker does not use the i2c to 
read the MAC address from eeprom at the SPL stage, which is at uboot.

Another thing 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.

> 
> If David or you send me a git branch to compile I will test it.
> 
> Has any of the rk3288 boards been tested before merging?

Yes,
I tested the patch at RK3288 PopMetal board once, and just tested one 
board for per Soc, i didn't have a Tinker board in my hand to verify it.
The new pinctrl driver could work at PopMetal:

U-Boot SPL 2019.01-rc1-00009-gdd7b9156fe (Feb 12 2019 - 09:33:17 +0800)
Returning to boot ROM...


U-Boot 2019.01-rc1-00009-gdd7b9156fe (Feb 12 2019 - 09:33:17 +0800)

Model: PopMetal-RK3288
DRAM:  2 GiB
MMC:   dwmmc at ff0c0000: 1, dwmmc at ff0f0000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default 
environment

In:    serial
Out:   serial
Err:   serial
Model: PopMetal-RK3288
Net:   eth-1: ethernet at ff290000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
** No partition table - mmc 0 **
Card did not respond to voltage select!
starting USB...
USB0:   scanning bus 0 for devices... 2 USB Device(s) found
        scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
No ethernet found.
=>

> 
> I think we should keep Simon in CC as he is one of the ROCKCHIP maintainers.
> 
> Best regards
> 
> Heinrich
> 
> 
> 

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

[Jack Mitchell]

On 09/02/2019 12:12, Heinrich Schuchardt wrote:
> Hello Simon, hello Philipp,
> 
> since patch
> 
> Merge tag 'for-master-20190201' of git://git.denx.de/u-boot-rockchip
> e5fd39c886485e3dec77f4438a6e364c2987cf5f
> 
> booting on the Tinker Board (tinker-rk3288_defconfig) is broken.
> 
> There is not even any UART output from SPL.
> 
> Best regards
> 
> Heinrich

I just tested the firefly rk3288 on current HEAD and all seems ok.

U-Boot SPL 2019.04-rc1-00067-gdbe70c7d4e (Feb 11 2019 - 10:26:48 +0000)
Returning to boot ROM...


U-Boot 2019.04-rc1-00067-gdbe70c7d4e (Feb 11 2019 - 10:26:48 +0000)

Model: Firefly-RK3288
DRAM:  4 GiB
MMC:   dwmmc at ff0c0000: 1, dwmmc at ff0f0000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default
environment

In:    serial
Out:   serial
Err:   serial
Model: Firefly-RK3288
Net:   Error enabling phy supply
eth-1: ethernet at ff290000
Hit any key to stop autoboot:  0
=>

Maybe try the matching commit or diff the firefly/tinker defconfigs to
look for clues.