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)



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