[U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken
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
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
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.,
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
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.
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...
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...
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...
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...
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?
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.
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...
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...
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.
在 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.
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?
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.
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).
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
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
On 2/17/19 9:19 AM, David Wu wrote:
Hi Henrich,
在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
On 2/13/19 11:56 AM, Philipp Tomsich wrote:
<snip>
Hello David, hello Philipp,
what are your ideas to reduce the SPL size to under 0x7800 again? Or will you move all rk3288 boards to TPL like TARGET_VYASA_RK3288?
CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can make spl boot. As the Tinker does not use the i2c to read the MAC address from eeprom at the SPL stage, which is at uboot.
Hello David,
the SPL image size now just fits: Image Type: Rockchip RK32 (SD/MMC) boot image Data Size: 30720 bytes
SPL is successful. But MMC is failing in main U-Boot:
``` U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 +0100) Returning to boot ROM...
U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 +0100)
Model: Tinker-RK3288 DRAM: 2 GiB MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ```
No further output here.
With some debug output enabled:
``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2)
U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100)
Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ```
Any suggestion how to proceed?
CC: Jaehoon.
Best regards
Heinrich
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@ff0c0000: 1 Loading Environment from MMC...No further output here.
With some debug output enabled:
U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC...Any suggestion how to proceed?
CC: Jaehoon.
Best regards
Heinrich
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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@ff0c0000: 1 Loading Environment from MMC... ``` No further output here. With some debug output enabled: ``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ``` Any suggestion how to proceed? CC: Jaehoon. Best regards Heinrich
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@ff0c0000: 1 Loading Environment from MMC... ``` No further output here. With some debug output enabled: ``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ``` Any suggestion how to proceed? CC: Jaehoon. Best regards Heinrich
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:
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@ff0c0000: 1 Loading Environment from MMC... ``` No further output here. With some debug output enabled: ``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ``` Any suggestion how to proceed? CC: Jaehoon. Best regards Heinrich
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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@ff0c0000: 1 Loading Environment from MMC... ``` No further output here. With some debug output enabled: ``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ``` Any suggestion how to proceed? CC: Jaehoon. Best regards Heinrich
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot
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@ff0c0000: 1 Loading Environment from MMC... ``` No further output here. With some debug output enabled: ``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ``` Any suggestion how to proceed? CC: Jaehoon. Best regards Heinrich
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot>
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot
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@ff0c0000: 1 Loading Environment from MMC... ``` No further output here. With some debug output enabled: ``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ``` Any suggestion how to proceed? CC: Jaehoon. Best regards Heinrich
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot>
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot
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@ff0c0000: 1 > Loading Environment from MMC... > ``` > > No further output here. > > With some debug output enabled: > > ``` > U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - > 13:05:10 > +0100) > Returning to boot ROM... > mmc_bind: alias ret=0, devnum=1 > env_init: Environment MMC init done (ret=-2) > > > U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - > 13:05:10 > +0100) > > Model: Tinker-RK3288 > DRAM: 2 GiB > mmc_bind: alias ret=0, devnum=1 > MMC: dwmmc@ff0c0000: 1 > Loading Environment from MMC... > ``` > > Any suggestion how to proceed? > > CC: Jaehoon. > > Best regards > > Heinrich
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot>
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot
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:
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@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@ff0c0000: 1 Loading Environment from MMC... ```
No further output here.
With some debug output enabled:
``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2)
U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100)
Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ```
Any suggestion how to proceed?
CC: Jaehoon.
Best regards
Heinrich
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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@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@gmx.de mailto:xypron.glpk@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@ff0c0000: 1 Loading Environment from MMC... ``` No further output here. With some debug output enabled: ``` U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Returning to boot ROM... mmc_bind: alias ret=0, devnum=1 env_init: Environment MMC init done (ret=-2) U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10 +0100) Model: Tinker-RK3288 DRAM: 2 GiB mmc_bind: alias ret=0, devnum=1 MMC: dwmmc@ff0c0000: 1 Loading Environment from MMC... ``` Any suggestion how to proceed? CC: Jaehoon. Best regards Heinrich
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot https://lists.denx.de/listinfo/u-boot
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.
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
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.
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
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!
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@ff0c0000: 1, dwmmc@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@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
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@ff0c0000: 1, dwmmc@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@ff290000 Hit any key to stop autoboot: 0 =>
Maybe try the matching commit or diff the firefly/tinker defconfigs to look for clues.
participants (7)
-
David Wu -
Heiko Stübner -
Heinrich Schuchardt -
Jack Mitchell -
Michael Nazzareno Trimarchi -
Philipp Tomsich -
Tom Rini