NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-evbarm/52984 (RPI/earmv6hf and earmv7hf: omxplayer abort trap)



The following reply was made to PR port-evbarm/52984; it has been noted by GNATS.

From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost, port-evbarm-maintainer%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, jun%soum.co.jp@localhost,
 Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>
Cc: 
Subject: Re: port-evbarm/52984 (RPI/earmv6hf and earmv7hf: omxplayer abort
 trap)
Date: Tue, 21 Aug 2018 08:16:31 +0100

 On 21/08/2018 00:15, Rin Okuyama wrote:
 > The following reply was made to PR port-evbarm/52984; it has been noted by GNATS.
 > 
 > From: Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: port-evbarm/52984 (RPI/earmv6hf and earmv7hf: omxplayer abort
 >   trap)
 > Date: Tue, 21 Aug 2018 08:12:53 +0900
 > 
 >   By using a dirty hack, omxplayer works fine on kernel from -current!
 >   The point is to stop GPU loading FDT blob, as I suggested in the	
 >   previous message. The procedure is as follows:
 >   
 >   (1) Boot kernel normally. Then, dump fdt_data:
 >   
 >   https://nxr.netbsd.org/xref/src/sys/arch/evbarm/fdt/fdt_machdep.c#106
 >   
 >        fdt_data is a copy of FDT blob which GPU makes from /boot/*.dtb.
 >   
 >   (2) Embed dumped FDT blob into data section of kernel.
 >   
 >   (3) Copy kernel (netbsd.bin) into /boot/kernel7.img (i.e., GPU does
 >        not load *.dtb files).
 >   
 >   Then, omxplayer works fine.
 >   
 >   This indicates that (A) GPU is not initialized if *.dtb is provided,
 >   or (B) GPU is initialized but its state is broken by loading *.dtb.
 >   
 >   I will take a look what Linux and FreeBSD deal with this problem.
 >   
 > 
 
 Is it because the memory ranges passed from the firmware are incorrect 
 or incorrectly handled some way so that bcm283[56]_dma_ranges doesn't 
 cover the memory then used by vchiq?
 
 https://nxr.netbsd.org/xref/src/sys/arch/arm/broadcom/bcm283x_platform.c#645
 
 Just guessing
 
 Nick
 


Home | Main Index | Thread Index | Old Index