Bug #17
closed
NTSC crashing on some builds
Added by foft over 7 years ago.
Updated almost 7 years ago.
Description
Investigate why... On the v1 core this occurred when running the PLL at very high fVCO. However we already fixed that in v1, so not sure why.
Ijor recommended I try registering the input directly from SDRAM. I've done this and see if it helps.
He is also kindly helping me write some correct timequest rules, really appreciated:)
I've still had bad builds since registering the sdram input directly.
I tried to specify an externally switchable input clock for timequest as a proxy for ntsc/pal clocks. However it doesn't make it past derive_pll_clocks, so I guess I need to define multiple pll outputs. I'm not sure of the impact here in terms of clock grouping definitions etc.
Interesting when I build on AWS I get completely screwed up builds with the registered sdram input. Seemingly every time.
- Priority changed from Normal to High
changed the Core to v8 and when chancing the video mode to NTSC the screen crashes
Nir
ndary wrote:
changed the Core to v8 and when chancing the video mode to NTSC the screen crashes
Nir
I remember that this was ok in mine board. Are you use the prototype 2 area to get the firmware?
- Related to Bug #34: Problem booting with Core 9 added
- Priority changed from High to Normal
Not seen this for months, think it was an issue around this time that has been fixed. Marking as normal priority for now.
- Status changed from New to Closed
On second thoughts... closing until we see it again.
Also available in: Atom
PDF