[U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

[Qu Wenruo]

On 2019/11/9 下午9:45, Jagan Teki wrote:
> On Sat, Nov 9, 2019 at 6:48 PM Qu Wenruo <quwenruo.btrfs at gmx.com> wrote:
>>
>>
>>
>> On 2019/11/9 下午8:25, Jagan Teki wrote:
>>> On Sat, Nov 9, 2019 at 12:08 PM Qu Wenruo <quwenruo.btrfs at gmx.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Although recent U-boot upstream has merged the rk3399 ram patchset to
>>>> initial DDR4 properly, but strangely I can still trigger SError for
>>>> RockPi4 and RockPro64 boards using upstream U-boot with upstream kernel
>>>> (v5.4-rc). The dmesg is attached at the end.
>>>>
>>>> This is pretty easy to trigger if using "memtester 3584M" (both boards
>>>> are 4G RAM variants).
>>>> The strange part is, if using the vendor uboot (like Armbian does), then
>>>> the kernel SError just goes away, so it looks like a bug in Uboot.
>>>
>>> Can you check u-boot memtest, past me the result.
>>
>> Looks like rockpi4 (maybe the whole rk3399 family) doesn't define
>> CONFIG_SYS_MEMTEST_START/END, thus enabling CONFIG_CMD_MEMTEST will
>> easily break the compile.
>>
>> Or any magic number for me to try?
> 
> Better try START with ddr base, and END some 256M set for basic test.

Not familiar enough for setting this up. :(

Is that memtest the best way to pin down the bug?

> 
>>
>>>
>>>>
>>>> The U-boot I built follows the README.rockchip, using the SD card and
>>>> boot option 1 (miniloader + Uboot + rkbin).
>>>> The script build script (arch PKGBUILD) can be found here:
>>>>
>>>> https://github.com/adam900710/PKGBUILDs/blob/rockpi4/alarm/uboot-rockpi4/PKGBUILD
>>>>
>>>> Any clue for the problem?
>>>
>>> Would you check this series [1]
>>>
>>> [1] https://patchwork.ozlabs.org/cover/1183700/
>>>
>> Any git repo? I hate to apply large patchset especially when there are
>> conflicts...
> 
> Hmm.. I didn't find the repo on the cover-letter. Did you check the
> u-boot-kerveryang github, may be Kever would place these on that repo
> I think.
> 

No luck. Anyway I'll try to solve the conflicts, as that's more feasible
to me.

Thanks,
Qu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191109/b2b25890/attachment.sig>