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

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

[Qu Wenruo]

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.

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?

Thanks,
Qu


Dmesg:

[16515.304212] SError Interrupt on CPU4, code 0xbf000000 -- SError
[16515.304214] CPU: 4 PID: 312266 Comm: xz Tainted: G             L
5.4.0-rc4-1-ARCH #1
[16515.304214] Hardware name: Pine64 RockPro64 (DT)
[16515.304215] pstate: 20000005 (nzCv daif -PAN -UAO)
[16515.304216] pc : __arch_copy_from_user+0x1e4/0x240
[16515.304217] lr : copyin+0x64/0x78
[16515.304217] sp : ffff800018a6ba60
[16515.304218] x29: ffff800018a6ba60 x28: 0000000000000000
[16515.304220] x27: ffff800018a6bbb0 x26: 0000000000001000
[16515.304222] x25: 0000000000000000 x24: 0000000000001000
[16515.304224] x23: ffff800018a6bd50 x22: ffff000009c01000
[16515.304225] x21: ffff800018a6bd40 x20: 0000000000001000
[16515.304227] x19: 0000000000000000 x18: 0000000000000000
[16515.304228] x17: 0000000000000000 x16: 0000000000000000
[16515.304230] x15: 0000000000000000 x14: 4f7d52dec520356f
[16515.304231] x13: a9de684a303f24f9 x12: 834588c331acaa6b
[16515.304233] x11: f7ff400b020fdd35 x10: 50b30156ca1b1f55
[16515.304234] x9 : 151da96d9c26e661 x8 : 4d11af6b86f45b1e
[16515.304236] x7 : 5da170ed6e6fbe74 x6 : ffff000009c00240
[16515.304238] x5 : ffff000009c01000 x4 : 0000000000000000
[16515.304239] x3 : 0000aaaac54c2290 x2 : 0000000000000d80
[16515.304241] x1 : 0000aaaac54c2500 x0 : ffff000009c00000
[16515.304243] Kernel panic - not syncing: Asynchronous SError Interrupt
[16515.304244] CPU: 4 PID: 312266 Comm: xz Tainted: G             L
5.4.0-rc4-1-ARCH #1
[16515.304245] Hardware name: Pine64 RockPro64 (DT)
[16515.304245] Call trace:
[16515.304246]  dump_backtrace+0x0/0x178
[16515.304246]  show_stack+0x24/0x30
[16515.304247]  dump_stack+0xa8/0xd0
[16515.304248]  panic+0x148/0x320
[16515.304248]  __stack_chk_fail+0x0/0x28
[16515.304249]  arm64_serror_panic+0x84/0x90
[16515.304249]  do_serror+0x7c/0x120
[16515.304250]  el1_error+0x84/0xf8
[16515.304251]  __arch_copy_from_user+0x1e4/0x240
[16515.304251]  iov_iter_copy_from_user_atomic+0xe8/0x388
[16515.304252]  iomap_write_actor+0xd0/0x190
[16515.304253]  iomap_apply+0xcc/0x150
[16515.304253]  iomap_file_buffered_write+0x78/0xa8
[16515.304254]  xfs_file_buffered_aio_write+0xd8/0x340
[16515.304255]  xfs_file_write_iter+0xd4/0xe8
[16515.304255]  new_sync_write+0x114/0x198
[16515.304256]  __vfs_write+0x74/0x90
[16515.304257]  vfs_write+0xbc/0x1c8
[16515.304257]  ksys_write+0x74/0xf8
[16515.304258]  __arm64_sys_write+0x24/0x30
[16515.304258]  el0_svc_handler+0xa4/0x188
[16515.304259]  el0_svc+0x8/0xc
[16515.304273] SMP: stopping secondary CPUs
[16515.304274] Kernel Offset: disabled
[16515.304274] CPU features: 0x0002,20006008
[16515.304275] Memory Limit: none

-------------- 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/1ff96530/attachment.sig>

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

[Jagan Teki]

On Sat, Nov 9, 2019 at 12:08 PM Qu Wenruo <quwenruo.btrfs@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.

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

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

[Qu Wenruo]

On 2019/11/9 下午8:25, Jagan Teki wrote:
> On Sat, Nov 9, 2019 at 12:08 PM Qu Wenruo <quwenruo.btrfs@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?

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

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

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

[Jagan Teki]

On Sat, Nov 9, 2019 at 6:48 PM Qu Wenruo <quwenruo.btrfs@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@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] 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@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@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>

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

[Qu Wenruo]

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.

Thanks,
Qu

On 2019/11/9 下午9:45, Jagan Teki wrote:
> On Sat, Nov 9, 2019 at 6:48 PM Qu Wenruo <quwenruo.btrfs@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@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.
> 

-------------- 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/77af9e2a/attachment.sig>

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

[Qu Wenruo]

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

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

[Soeren Moch]

> 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.
For me this patch [1] solved this kind of problems on my RockPro64. Can
you please test this patch?

Thanks,
Soeren

[1] https://patchwork.ozlabs.org/patch/1191078/
> 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@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@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] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

[Anand Moon]

Hi Qu Wenruo,

On Fri, 15 Nov 2019 at 17:27, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> 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

Please this following series of patches for fix this error.
It fixed issue of SError on my board.

[0] https://patchwork.ozlabs.org/cover/1195284/

Best Regards
-Anand

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

[Qu Wenruo]

On 2019/11/15 下午10:07, Soeren Moch wrote:
> 
>> 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.
> For me this patch [1] solved this kind of problems on my RockPro64. Can
> you please test this patch?
> 
> Thanks,
> Soeren
> 
> [1] https://patchwork.ozlabs.org/patch/1191078/

Applied and tested on v2019.10 tag.

Unfortunately, no help. Still SError crash.

Thanks,
Qu

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

-------------- 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/20191116/e02d58e3/attachment-0001.sig>

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

[Qu Wenruo]

On 2019/11/15 下午10:59, Anand Moon wrote:
> Hi Qu Wenruo,
> 
> On Fri, 15 Nov 2019 at 17:27, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> 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
> 
> Please this following series of patches for fix this error.
> It fixed issue of SError on my board.

Would you mind to share which commit it is based?

For v2019.10 tag, it fails at the 13th patch.
The same happened for current master.

Thanks,
Qu
> 
> [0] https://patchwork.ozlabs.org/cover/1195284/
> 
> Best Regards
> -Anand
> 

-------------- 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/20191116/74f6fab4/attachment.sig>

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

[Qu Wenruo]

On 2019/11/16 下午1:16, Qu Wenruo wrote:
> 
> 
> On 2019/11/15 下午10:59, Anand Moon wrote:
>> Hi Qu Wenruo,
>>
>> On Fri, 15 Nov 2019 at 17:27, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>
>>>
>>>
>>> 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
>>
>> Please this following series of patches for fix this error.
>> It fixed issue of SError on my board.
> 
> Would you mind to share which commit it is based?
> 
> For v2019.10 tag, it fails at the 13th patch.
> The same happened for current master.

Well, manually solved the conflicts.

If anyone is interested in using that, I have uploaded it to github,
which is based on v2019.10 tag:

https://github.com/adam900710/u-boot/tree/serror_fixes

Unfortunately, still crashed for memtester 3584M.

Thanks,
Qu

> 
> Thanks,
> Qu
>>
>> [0] https://patchwork.ozlabs.org/cover/1195284/
>>
>> Best Regards
>> -Anand
>>
> 
> 
> _______________________________________________
> 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/20191116/c1a87e82/attachment.sig>

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

[Kever Yang]

Hi Qu Wenruo,


     Please try with latest u-boot-rockchip with dram and board fix merged:

https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git master branch


     Did you try with rkbin ddr.bin instead of TPL and keep other 
firmware(SPL, U-Boot, ATF),

this can confirm if there is something wrong in TPL dram driver or not.


Thanks,

- Kever

On 2019/11/16 下午1:39, Qu Wenruo wrote:
>
> On 2019/11/16 下午1:16, Qu Wenruo wrote:
>>
>> On 2019/11/15 下午10:59, Anand Moon wrote:
>>> Hi Qu Wenruo,
>>>
>>> On Fri, 15 Nov 2019 at 17:27, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>
>>>>
>>>> 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
>>> Please this following series of patches for fix this error.
>>> It fixed issue of SError on my board.
>> Would you mind to share which commit it is based?
>>
>> For v2019.10 tag, it fails at the 13th patch.
>> The same happened for current master.
> Well, manually solved the conflicts.
>
> If anyone is interested in using that, I have uploaded it to github,
> which is based on v2019.10 tag:
>
> https://github.com/adam900710/u-boot/tree/serror_fixes
>
> Unfortunately, still crashed for memtester 3584M.
>
> Thanks,
> Qu
>
>> Thanks,
>> Qu
>>> [0] https://patchwork.ozlabs.org/cover/1195284/
>>>
>>> Best Regards
>>> -Anand
>>>
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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

[Qu Wenruo]

On 2019/11/18 上午10:51, Kever Yang wrote:
> Hi Qu Wenruo,
> 
> 
>     Please try with latest u-boot-rockchip with dram and board fix merged:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git master branch

Thanks, I'll take a try if it can compile on Arch, (as dtc include
changed on Arch, and that's the reason I'm sticking to upstream U-boot)

> 
> 
>     Did you try with rkbin ddr.bin instead of TPL and keep other
> firmware(SPL, U-Boot, ATF),

Always using rkbin + miniloader version.
Never tried the other boot flow, due to the need to compile using M0
toolchain (I'm doing native compile, and Archlinuxarm doesn't provide M0
toolchain for aarch64 platform).

Thanks,
Qu

> 
> this can confirm if there is something wrong in TPL dram driver or not.
> 
> 
> Thanks,
> 
> - Kever
> 
> On 2019/11/16 下午1:39, Qu Wenruo wrote:
>> On 2019/11/16 下午1:16, Qu Wenruo wrote:
>>> On 2019/11/15 下午10:59, Anand Moon wrote:
>>>> Hi Qu Wenruo,
>>>>
>>>> On Fri, 15 Nov 2019 at 17:27, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>>
>>>>> 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
>>>> Please this following series of patches for fix this error.
>>>> It fixed issue of SError on my board.
>>> Would you mind to share which commit it is based?
>>>
>>> For v2019.10 tag, it fails at the 13th patch.
>>> The same happened for current master.
>> Well, manually solved the conflicts.
>>
>> If anyone is interested in using that, I have uploaded it to github,
>> which is based on v2019.10 tag:
>>
>> https://github.com/adam900710/u-boot/tree/serror_fixes
>>
>> Unfortunately, still crashed for memtester 3584M.
>>
>> Thanks,
>> Qu
>>
>>> Thanks,
>>> Qu
>>>> [0] https://patchwork.ozlabs.org/cover/1195284/
>>>>
>>>> Best Regards
>>>> -Anand
>>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>>
>>
>> _______________________________________________
>> 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/20191118/115971fb/attachment.sig>

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

[Qu Wenruo]

On 2019/11/18 上午10:51, Kever Yang wrote:
> Hi Qu Wenruo,
> 
> 
>     Please try with latest u-boot-rockchip with dram and board fix merged:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git master branch

Compiled and installed, and still the same SError trying "memtest 3584M"
on my RockPi4 (4G RAM variant)

I guess now it's time to blame the rkbin I used?

The rkbin files I'm using is:
rk3399_ddr_800MHz_v1.23.bin
rk3399_miniloader_v1.19.bin

And for the trust.ini, it's
---
[VERSION]
MAJOR=1
MINOR=0
[BL30_OPTION]
SEC=0
[BL31_OPTION]
SEC=1
PATH=../rkbin/bin/rk33/rk3399_bl31_v1.29.elf
ADDR=0x00010000
[BL32_OPTION]
SEC=1
PATH=../rkbin/bin/rk33/rk3399_bl32_v1.20.bin
ADDR=0x08400000
[BL33_OPTION]
SEC=0
[OUTPUT]
PATH=trust.img
---

Since I'm completely new to the rk3399 boot sequence, would it be
possible that above binary files caused the problem?

Thanks,
Qu
> 
> 
>     Did you try with rkbin ddr.bin instead of TPL and keep other
> firmware(SPL, U-Boot, ATF),
> 
> this can confirm if there is something wrong in TPL dram driver or not.
> 
> 
> Thanks,
> 
> - Kever
> 
> On 2019/11/16 下午1:39, Qu Wenruo wrote:
>> On 2019/11/16 下午1:16, Qu Wenruo wrote:
>>> On 2019/11/15 下午10:59, Anand Moon wrote:
>>>> Hi Qu Wenruo,
>>>>
>>>> On Fri, 15 Nov 2019 at 17:27, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>>
>>>>> 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
>>>> Please this following series of patches for fix this error.
>>>> It fixed issue of SError on my board.
>>> Would you mind to share which commit it is based?
>>>
>>> For v2019.10 tag, it fails at the 13th patch.
>>> The same happened for current master.
>> Well, manually solved the conflicts.
>>
>> If anyone is interested in using that, I have uploaded it to github,
>> which is based on v2019.10 tag:
>>
>> https://github.com/adam900710/u-boot/tree/serror_fixes
>>
>> Unfortunately, still crashed for memtester 3584M.
>>
>> Thanks,
>> Qu
>>
>>> Thanks,
>>> Qu
>>>> [0] https://patchwork.ozlabs.org/cover/1195284/
>>>>
>>>> Best Regards
>>>> -Anand
>>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>>
>>
>> _______________________________________________
>> 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/20191118/4b828e34/attachment.sig>