RockPro64 with u-boot 2010.01

[Emmanuel Vadot]

On Tue, 3 Mar 2020 11:28:56 +0100
Bernd Walter <ticso at cicely7.cicely.de> wrote:

> On Tue, Mar 03, 2020 at 02:12:19AM +0100, Klaus Küchemann wrote:
> > Hi Bernd,
> > 
> > exclusively made only for you ;-)  :
> > 
> > https://wiki.freebsd.org/arm64/ROCKPro64 <https://wiki.freebsd.org/arm64/ROCKPro64>
> 
> 
> Perfect - it works :-)
> Thank you very much.
> 
> What have you done differently than me?
> Beside that I noticed you've changed to console speed to more sane 115200bps.
> 
> Well - I now have a new problem, which I've only noticed because I had
> the USB reader left plugged in since yesterday.
> It worked with the previous u-boot (and 2G RAM).
> 
> FreeBSD/arm64 (generic) (ttyu1)
> 
> login: ugen4.2: <SanDisk SDDR-B531> at usbus4
> umass0 on uhub3
> umass0: <SanDisk SDDR-B531, class 0/0, rev 3.10/29.16, addr 1> on usbus4
> umass0:  SCSI over Bulk-Only; quirks = 0x8100
> umass0:0:0: Attached to scbus0
> (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 
> (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
> (probe0:umass-sim0:0:0:0): SCSI status: Check Condition
> (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
> (probe0:umass-sim0:0:0:0): Error 22, Unretryable error
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex CAM device lock (CAM device lock) r = 0 (0xfffffd0015619cd0) locked @ /usr/src/sys/cam/cam_xpt.c:5477
> stack backtrace:
> #0 0xffff000000476d7c at witness_debugger+0x64
> #1 0xffff000000477dc4 at witness_warn+0x400
> #2 0xffff000000770aa8 at data_abort+0xec
> #3 0xffff00000076fee8 at do_el1h_sync+0x144
> #4 0xffff000000754078 at handle_el1h_sync+0x78
> #5 0xffff0000003e5ef0 at free+0x64
> #6 0xffff00000002d95c at probedone+0xabc
> #7 0xffff00000001c47c at xpt_done_process+0x364
> #8 0xffff00000001e120 at xpt_done_td+0xd8
> #9 0xffff0000003cba58 at fork_exit+0x7c
>   x0:                0
>   x1:                0
>   x2:               21
>   x3:              39d
>   x4: fffffd00ecd8e200
>   x5:               44
>   x6:              11c
>   x7: ffff0000403670b0
>   x8:                1
>   x9: ffff0000404b9100
>  x10:               21
>  x11:                0
>  x12: ffff000000d44a18
>  x13: ffff000000d44998
>  x14:                1
>  x15:                0
>  x16:                1
>  x17:                0
>  x18: ffff0000403676a0
>  x19: ffff0000009aae48
>  x20: fffffd00e947e9f8
>  x21: fffffd00e947e000
>  x22:              280
>  x23: fffffd00e947e9f8
>  x24: ffff0000403678f0
>  x25: fffffd000370b100
>  x26: fffffd0060045810
>  x27: fffffd0003514500
>  x28: fffffd0060045800
>  x29: ffff0000403676c0
>   sp: ffff0000403676a0
>   lr: ffff0000003e5ef4
>  elr: ffff0000003e5ef4
> spsr:         20000145
>  far:                0
>  esr:         96000005
> panic: data abort in critical section or under mutex
> cpuid = 2
> time = 1583230709
> KDB: stack backtrace:
> db_trace_self() at db_trace_self_wrapper+0x28
>          pc = 0xffff000000751a5c  lr = 0xffff000000106be8
>          sp = 0xffff000040367090  fp = 0xffff0000403672a0
> 
> db_trace_self_wrapper() at vpanic+0x194
>          pc = 0xffff000000106be8  lr = 0xffff00000040e378
>          sp = 0xffff0000403672b0  fp = 0xffff000040367360
> 
> vpanic() at panic+0x44
>          pc = 0xffff00000040e378  lr = 0xffff00000040e120
>          sp = 0xffff000040367370  fp = 0xffff0000403673f0
> 
> panic() at data_abort+0x250
>          pc = 0xffff00000040e120  lr = 0xffff000000770c0c
>          sp = 0xffff000040367400  fp = 0xffff0000403674b0
> 
> data_abort() at do_el1h_sync+0x144
>          pc = 0xffff000000770c0c  lr = 0xffff00000076fee8
>          sp = 0xffff0000403674c0  fp = 0xffff0000403674f0
> 
> do_el1h_sync() at handle_el1h_sync+0x78
>          pc = 0xffff00000076fee8  lr = 0xffff000000754078
>          sp = 0xffff000040367500  fp = 0xffff000040367610
> 
> handle_el1h_sync() at free+0x64
>          pc = 0xffff000000754078  lr = 0xffff0000003e5ef0
>          sp = 0xffff000040367620  fp = 0xffff0000403676c0
> 
> free() at probedone+0xabc
>          pc = 0xffff0000003e5ef0  lr = 0xffff00000002d95c
>          sp = 0xffff0000403676d0  fp = 0xffff0000403678b0
> 
> probedone() at xpt_done_process+0x364
>          pc = 0xffff00000002d95c  lr = 0xffff00000001c47c
>          sp = 0xffff0000403678c0  fp = 0xffff0000403678e0
> 
> xpt_done_process() at xpt_done_td+0xd8
>          pc = 0xffff00000001c47c  lr = 0xffff00000001e120
>          sp = 0xffff0000403678f0  fp = 0xffff000040367940
> 
> xpt_done_td() at fork_exit+0x7c
>          pc = 0xffff00000001e120  lr = 0xffff0000003cba58
>          sp = 0xffff000040367950  fp = 0xffff000040367980
> 
> fork_exit() at fork_trampoline+0x10
>          pc = 0xffff0000003cba58  lr = 0xffff00000076fc1c
>          sp = 0xffff000040367990  fp = 0x0000000000000000
> 
> KDB: enter: panic
> [ thread pid 9 tid 100042 ]
> Stopped at      free+0x68:      ldr     x2, [x0]
> db> 
> 
> -- 
> B.Walter <bernd at bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

 Try with hw.ncpu=4 in /boot/loader.conf
 There is some issue wrt big.LITTLE, this is not the same panic that I
see but could be the same root problem.

-- 
Emmanuel Vadot <manu at bidouilliste.com>