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

Qu Wenruo quwenruo.btrfs at gmx.com
Fri Nov 15 11:57:25 UTC 2019



On 2019/11/15 下午6:37, Qu Wenruo wrote:
> A small update to this bug.
> 
> I'm using mem=3584M kernel cmdline, to sacrifice 512M memory.
> 
> And then surprise, memtest 3G works. (Originally it's 4G physical ram
> and 3584M memtest.
> 
> Hopes this could provide some clue.

Oh no, with 3187M, it still crashes with SError.

So still no luck.

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

-------------- 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/20191115/e836c295/attachment.sig>


More information about the U-Boot mailing list