| 23:59 | dv__ | the LED is software-controlled, isnt it? |
| 00:00 | twitch153 | dv__, I was under the assumption that the LED turned on as soon as power came to the system. |
| 00:00 | dv_ | hmm yes this could be |
| 00:00 | dv_ | either that, or U-Boot enables it |
| 00:00 | twitch153 | Possible. But I never touched U-Boot. |
| 00:01 | twitch153 | Well, I'm with dexter93 working on this. |
| 00:01 | twitch153 | So when I say I, I mean the both of us. |
| 00:01 | dv_ | then it is probably not bricked by software |
| 00:01 | dv_ | sounds more like broken hardware |
| 00:01 | twitch153 | That's what I was saying. |
| 00:02 | dv_ | that's unfortunate :/ I'd recommend to send a mail to solid-run about this, as rabeeh is plenty busy and often not really on here |
| 00:02 | dexter93 | We did. Rabeeh told us to get here |
| 00:02 | twitch153 | That's what we did, but we haven't gotten a reply, it's been a couple of weeks. |
| 00:04 | dv_ | oh |
| 00:04 | dv_ | it seems they dont have enough staff :) |
| 00:04 | twitch153 | It's a little bothersome because we have a 3 month warranty on it, but with the lack of response that'll be up before they even reply xD |
| 00:05 | dexter93 | Seems so. And timezones don't help much |
| 00:05 | dexter93 | Indeed |
| 00:06 | dv_ | well I wish I could help, but I am not an employee either |
| 00:06 | twitch153 | Of course :) |
| 00:08 | _rmk_ | is it the case that it was DoA ? |
| 00:09 | twitch153 | _rmk_, no. We tried hooking it up to the computer to do Serial over USB, to use the Cubox upgrader tool. |
| 00:10 | twitch153 | When we got to that step, the light turned off and the cubox was dead. I'm assuming it might have received too much current from the computer, but regardless of what happened, that should not be the case to cause the death to the cubox. Ya know? |
| 00:10 | dv_ | oh |
| 00:10 | twitch153 | It wouldn't turn on no matter how long it was connected to the power supply. |
| 00:10 | dv_ | the upgrader tool didnt get to download anything into the cubox, it turned off right away, correct? |
| 00:11 | twitch153 | dv_, it didn't download anything, correct. |
| 00:11 | _rmk_ | does your computer still recognise when the cubox is connected via USB? |
| 00:11 | twitch153 | Yes. |
| 00:11 | twitch153 | The self-powered uart still works. |
| 00:12 | _rmk_ | ok, does the power brick that came with your cubox have a green LED on it, and I assume you've checked that that is illuminated? |
| 00:12 | twitch153 | Yeah. |
| 00:13 | _rmk_ | do you have something a USB keyboard you could try plugging into one of its USB sockets? |
| 00:14 | twitch153 | Yep. |
| 00:14 | _rmk_ | and does the keyboard show any signs of life when connected - eg, a flash of its own leds? |
| 00:14 | twitch153 | One sec. |
| 00:15 | _rmk_ | (to put that another way - do you see any power coming out from the USB sockets with the cubox connected to its power source) |
| 00:15 | twitch153 | No. |
| 00:16 | _rmk_ | ok, that sounds like not bricked, but hardware failure somewhere between the brick psu and cubox internals |
| 00:16 | twitch153 | That's what I figured. |
| 00:16 | _rmk_ | what's your electronics know-how like? |
| 00:16 | twitch153 | Pretty decent. |
| 00:17 | twitch153 | I know enough to know how to construct some circuits and use a multimeter. |
| 00:17 | _rmk_ | so if I asked whether you could put a multimeter on the end of the cubox's power cable? |
| 00:18 | twitch153 | I would tell you I've already done it :) |
| 00:19 | _rmk_ | and what did it read? |
| 00:20 | twitch153 | Well, I did it like last week. So I couldn't tell you the exact reading. But I know it was around the correct voltage and amperage. |
| 00:20 | _rmk_ | erm.. amperage... I hope you didn't put the meter across the psu output measuring current :) |
| 00:21 | twitch153 | Not like that, no. I measure it in a circuit I made, to ensure that the PSU was working correctly. |
| 00:22 | _rmk_ | well, that's about the limit of what can be done, but it sounds like you should return it to solid-run as "hardware failed shortly after arrival" |
| 00:27 | twitch153 | Sorry about that, someone thought it'd be bright to unplug the router. |
| 00:31 | shesselba | twitch153: unfortunately usb keyboard is not a good DoA test |
| 00:31 | shesselba | usb is powered off by default, u-boot needs to enable it |
| 00:31 | shesselba | if you/the updater bricked your cubox by accident, there is no LED and no USB powered |
| 00:32 | twitch153 | shesselba, what would you suggest? I'm open to trying anything :) |
| 00:32 | shesselba | best would be to hook up usb2serial, start minicom (linux, or some terminal on windows) |
| 00:33 | shesselba | push the little button hidden in that tiny hole on the back |
| 00:33 | shesselba | and power on |
| 00:33 | shesselba | you should see "something" if the board/soc is still alive |
| 00:34 | shesselba | You should see the UART boot mode requesting an image, cubox is basically "unbrickable" because of that |
| 00:35 | shesselba | I haven't checked wiki for a while, but if it responds, you will find an u-boot image there to reflash it |
| 00:35 | twitch153 | Alrighty, give me a sec to get it all together. So hook up the microUSB to the Cubox, then hook that up to the computer. Then start up minicom, and when I push that button the computer will likely request something? |
| 00:36 | shesselba | close |
| 00:36 | shesselba | ..., push the button, poweron cubox, release button |
| 00:37 | shesselba | what some secs before releasing the button, just to make sure |
| 00:37 | twitch153 | Gotcha. |
| 00:37 | shesselba | and your computer will not "request" something, you should see some unreadable characters on minicom |
| 00:37 | shesselba | thats all |
| 00:38 | shesselba | just a test if it is still alive |
| 00:38 | shesselba | minicom settings is 115200, 8n1 as always |
| 00:39 | twitch153 | shesselba, so I haven't connected the cubox to the computer yet (I need to install minicom on my laptop), but the cubox is hooked up to the power cable and the cubox is getting noticeably warmer. |
| 00:40 | shesselba | well, if something is broken, it will still get warm |
| 00:40 | shesselba | what distro are you on? |
| 00:41 | shesselba | also apt-get install lrzsz if on debian or ubuntu |
| 00:41 | twitch153 | shesselba, I'm on gentoo. |
| 00:41 | shesselba | dooh |
| 00:41 | shesselba | you need some xmodem tool, we will look it up later |
| 00:42 | twitch153 | The microUSB cable isn't connected to the computer at all yet though. I have the usb2serial driver cooked into my kernel as well. |
| 00:42 | shesselba | funky gentoo nerd ;) |
| 00:43 | twitch153 | xD |
| 00:43 | twitch153 | Can't help it. |
| 00:43 | shesselba | ok ready? |
| 00:43 | twitch153 | lrzsz is being brought in with minicom. |
| 00:44 | twitch153 | It's compiling it now ;) |
| 00:44 | shesselba | first check for any other usb-serial device: ls /dev/ttyU* |
| 00:45 | twitch153 | Nothing shows up. |
| 00:45 | shesselba | ok, plug in the microusb cable into your laptop with cubox connected |
| 00:45 | shesselba | redo ls /dev/ttyU* |
| 00:46 | twitch153 | Yep. It shows up. |
| 00:46 | shesselba | /dev/ttyUSB0, right? |
| 00:46 | twitch153 | Yes. |
| 00:46 | shesselba | is minicom done compiling? |
| 00:46 | twitch153 | Yep. |
| 00:47 | shesselba | now, minicom -D /dev/ttyUSB0 -b 115200 -8 |
| 00:48 | shesselba | find something tiny that fits into the hole on the back of cubox, e.g. paperclip |
| 00:49 | shesselba | turn off cubox (unplug power cable) |
| 00:50 | shesselba | get familiar with the button, press it, feel the "click" ? |
| 00:53 | shesselba | You have the 1G or 2G version? |
| 00:53 | twitch153 | 1G |
| 00:53 | shesselba | found the button? |
| 00:53 | twitch153 | Yessir, |
| 00:53 | shesselba | ok, press it, hold it, plug in power cable |
| 00:54 | shesselba | you see something on minicom? |
| 00:55 | twitch153 | shesselba, yeah. |
| 00:55 | shesselba | some unprintable character, new ones coming in every second or so? |
| 00:55 | twitch153 | Yep. |
| 00:55 | shesselba | great, so it is not dead |
| 00:56 | twitch153 | Okay, where do we go from here? |
| 00:56 | shesselba | unplug cubox for a while, you can release the button by the way ;) |
| 00:56 | shesselba | have wget? |
| 00:56 | shesselba | wget http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/apr-8-2013/u-boot-cubox_hynix_cubox_1GB_uart.bin |
| 00:57 | shesselba | in minicom, press Ctrl-A S |
| 00:57 | shesselba | select xmodem |
| 00:57 | _rmk_ | oh, there's a new uboot? |
| 00:57 | shesselba | and select that file you downloaded |
| 00:57 | shesselba | _rmk_: looks like, I am still on the very first version I guess ;) |
| 00:59 | shesselba | twitch153: navigation on minicom and selecting a file is a bit tricky.. either just make it ask for a filename, or IIRC "select" is double-space |
| 01:00 | _rmk_ | me too |
| 01:00 | shesselba | the game is: redo all the stuff above up to press button and plug power, then in minicom press Ctrl-A S, Xmodem and send the file |
| 01:01 | shesselba | when done you have u-boot running _in RAM_, check the wiki for instructions reflashing a new bootloader |
| 01:01 | dv_ | I always hesitate to update bootloaders |
| 01:01 | dv_ | if something gets screwed up, my poor cubox is bricked |
| 01:01 | shesselba | dv_: with uart boot mode, you are quite sage |
| 01:01 | shesselba | safe |
| 01:01 | twitch153 | shesselba, Retry o: NAK on sector. |
| 01:01 | twitch153 | This keeps popping up. They says "Retry 0: Retry count Exceeded" |
| 01:01 | twitch153 | s/o/0 |
| 01:02 | shesselba | twitch153: you powered it off again ? |
| 01:02 | _rmk_ | *argh* |
| 01:02 | shesselba | maybe try Ctrl-A S, Xmodem, send and then do the button thing |
| 01:02 | _rmk_ | looks like more work for me to do... 3.9 spat out this error while trying to read from the flash... spi_master spi0: failed to prepare transfer hardware |
| 01:02 | twitch153 | shesselba, it's not powered off. And okay. |
| 01:03 | shesselba | the button thing only works from unpowered state |
| 01:03 | shesselba | _rmk_: did I mess with spi? |
| 01:03 | shesselba | or somebody else? |
| 01:05 | _rmk_ | or it may be me |
| 01:05 | shesselba | last change in 3.10-rc6 is from feb 4 |
| 01:06 | shesselba | twitch153: success? |
| 01:06 | twitch153 | shesselba, trying again. That button combo is a pita. |
| 01:07 | _rmk_ | shesselba: I added runtime pm to it |
| 01:07 | shesselba | _rmk_: hmm |
| 01:07 | twitch153 | Retry 0: Timeout on sector ACK. |
| 01:07 | dv_ | _rmk_: what parts of the kernel contain stuff that is very marvell specific and requires their datasheets? |
| 01:08 | dv_ | I can think of vmeta and the galcore |
| 01:08 | dv_ | anything else? |
| 01:08 | shesselba | twitch153: It is simple, just make sure it is powered off, start xmodem transfer, press the button, power on |
| 01:08 | shesselba | dv_: galcore is not marvell |
| 01:08 | _rmk_ | those are the two big closed items that I can think of. I think everything else is documented in the functional spec which is pretty much searchable |
| 01:09 | dv_ | err, true, galcore is from vivante |
| 01:09 | twitch153 | shesselba, I did. It's timing out. |
| 01:09 | shesselba | twitch153: check minicom settings (Ctrl-A O) |
| 01:09 | dv_ | _rmk_: I ask because vmeta in particular is not documented at all, the "reference" only being a gstreamer plugin and some marvell-ipp examples |
| 01:09 | dv_ | so any bugs in the plugin and the examples will not be recognizable as such (unless it is quite obvious) |
| 01:09 | shesselba | make sure, 115200, 8bit, 1 stop, disable xon/xoff |
| 01:10 | dv_ | thats the old problem with example code being the "spec".. |
| 01:10 | _rmk_ | I've poked around in its registers and not made much sense from it, but then I didn't try all that hard |
| 01:12 | twitch153 | shesselba, I don't see where it says anything about xon/xoff. But the rest of the stuff is there. I ran minicom how you said to. |
| 01:12 | shesselba | let me check |
| 01:12 | _rmk_ | ^a o serial port setup |
| 01:12 | twitch153 | minicom -d /dev/ttyUSB0 -b 115200 -8 |
| 01:12 | _rmk_ | software flow control |
| 01:12 | shesselba | HW flow control = no, SW flow control = no |
| 01:13 | twitch153 | HW flow control was on. |
| 01:13 | shesselba | turn both off |
| 01:15 | twitch153 | Trying it again. |
| 01:18 | _rmk_ | bah. |
| 01:19 | _rmk | 01:19 * _rmk_ does this dance too |
| 01:19 | twitch153 | shesselba, okay, it looks like it's transferring now. |
| 01:19 | dv_ | the flow control thing is a common pitfall in the beginning |
| 01:19 | twitch153 | Okay, transferred. |
| 01:20 | twitch153 | Well, the light's back on. So that's good new. |
| 01:20 | twitch153 | *news |
| 01:21 | shesselba | twitch153: Great, now check out http://www.solid-run.com/mw/index.php/U-Boot, Section "Write to flash" - note that you can _always_ get a working u-boot by the procedure you just learned, but remember it is running in RAM, as soon as you reset/poweroff it will be gone |
| 01:21 | shesselba | you should see some u-boot output and prompt |
| 01:21 | twitch153 | Yeah, it says something about bad partition sectors. Which I'm assuming is referring to the SD card. |
| 01:23 | shesselba | dv_: maybe someone copies the last 25 minutes and prepares a "uart boot mode in a nut-shell" from it ;) |
| 01:23 | dv_ | heh |
| 01:23 | shesselba | or "is my cubox really bricked?" |
| 01:23 | twitch153 | shesselba, so I'm going to be looking at the section where it starts by saying "Then store the new bootloader on the internal flash:"? |
| 01:23 | shesselba | _rmk_: dancing what dance? |
| 01:23 | twitch153 | shesselba, I agree. It'll probably be pretty helpful if someone thinks their device is hardware bricked. |
| 01:23 | _rmk_ | the load-uboot-over-usb dance |
| 01:24 | shesselba | _rmk_: ooh, sooo easy to dance ;) at least compared to jtag ;) |
| 01:24 | shesselba | twitch153: you need the spi binary on some usb stick plugged into the upper port |
| 01:25 | shesselba | or fiddle with your sdcard (replace usb 0:1 by mmc 0:1) |
| 01:26 | shesselba | _rmk_: have a sony nsz-gs7 with armada 1500 here, tried to reverse eng the sony debug port. |
| 01:26 | shesselba | it is so damn locked :P |
| 01:26 | shesselba | I can make it boot from spi, but not more than 4k or so |
| 01:26 | dexter93 | Heh, turns out it was just stubborn. Thanks a lot shesselba |
| 01:26 | shesselba | np |
| 01:27 | shesselba | it also has some jtag but I cannot jtagscan it |
| 01:28 | shesselba | the layout is so obvious, but IIRC jtag is also a boot mode you need to strap .. and I haven't found the necessary test pads to pull |
| 01:28 | _rmk_ | helps to load the right version of uboot :) |
| 01:28 | dexter93 | The fun bit was that when we won it on the xda contest, we said we'd test it's unbrickability. Well.. it happened sooner than twitch153 and I thought xD |
| 01:28 | twitch153 | dexter93, shhh. |
| 01:28 | twitch153 | >:o |
| 01:28 | shesselba | hehe, from a SoC PoV it _is_ unbrickable |
| 01:29 | twitch153 | Yeah. |
| 01:29 | _rmk_ | right, willitwork this time |
| 01:29 | twitch153 | From a "smashing it with a brick" PoV it's not entirely unbrickable. |
| 01:29 | shesselba | Kirkwood also has the UART boot mode, but responds to some preamble sent on reset |
| 01:30 | shesselba | no need to press a tiny button ;) |
| 01:30 | shesselba | maybe marvell realized that it basically punches a huge hole in any attempt to secure your product ;) |
| 01:30 | _rmk_ | this time I'll try not dd'ing the spi image into a non-existent /dev/mtdblock0 :) |
| 01:31 | shesselba | hehe |
| 01:31 | shesselba | don't use cat either |
| 01:31 | _rmk_ | oh for the joys of udev and dynamic /dev |
| 01:32 | _rmk_ | should've realised this was too quick for dd: |
| 01:32 | _rmk_ | 339948 bytes (340 kB) copied, 0.162111 s, 2.1 MB/s |
| 01:32 | _rmk_ | 339948 bytes (340 kB) copied, 22.2295 s, 15.3 kB/s |
| 01:32 | _rmk_ | is more like it should be |
| 01:32 | shesselba | _rmk_: ever tried to find a dead disk on a cheap RAID controller? |
| 01:32 | _rmk_ | that worked :) |
| 01:32 | shesselba | or _the_ dead disk ? |
| 01:33 | _rmk_ | depends what you mean by "cheap raid controller" |
| 01:33 | twitch153 | shesselba, so basically I should use Cubox installer to install the new u-boot binary for me? |
| 01:34 | dv_ | _rmk_: regarding udev, I still am unsure whether or not to consider it a bit bloated |
| 01:34 | shesselba | _rmk_: don't recall the module name, maybe dmraid, in general "software managed RAID on cheap HW controller" |
| 01:35 | shesselba | twitch153: I cannot help you from here on, I never tried that. I started hacking on kernel stuff and never came to install any distro |
| 01:36 | _rmk_ | well, I know someone who used to work for bitwizard who used to curse the more expensive raid controllers |
| 01:36 | shesselba | although _rmk_ is possibly about to change that soon ;) |
| 01:36 | twitch153 | Gotcha. :) |
| 01:36 | _rmk_ | especially when people tried to "repair" their degrated arrays |
| 01:36 | _rmk_ | and ended up causing more corruption in the process |
| 01:37 | shesselba | well, we do suffer from dead disk sometimes |
| 01:37 | shesselba | while you can easily find the dead disk on storedge or even cheaper eonstor |
| 01:37 | _rmk_ | ... reminds me of a promise UDMA/33 card I had in a machine... where a label on the rear ate through one of the data lines between the UDMA add-on chip and the PCI-to-IDE chip |
| 01:37 | shesselba | you cannot on that onboard raid |
| 01:38 | _rmk_ | bit 13 randomly set or cleared in inode tables... fun. |
| 01:38 | _rmk_ | on _both_ drives |
| 01:38 | shesselba | hehe |
| 01:38 | _rmk_ | I repaired it and it still runs... it's now on an it8212 card and this irc client is on that very machine |
| 01:39 | _rmk_ | 00:39:03 up 1096 days, 1:14, 15 users, load average: 1.21, 1.36, 1.35 |
| 01:40 | _rmk_ | long overdue for an update of all types |
| 01:40 | shesselba | you don't .. yeah.. update much I wanted to say ;) |
| 01:40 | _rmk_ | that's an ebsa285 |
| 01:41 | shesselba | x86 HW? |
| 01:42 | _rmk_ | no, StrongARM |
| 01:42 | shesselba | uuuh, I know I have some HP portable with keyboard somewhere |
| 01:42 | shesselba | SA1100 |
| 01:43 | shesselba | Windows CE |
| 01:43 | shesselba | HP Jornada |
| 01:43 | _rmk_ | this is SA110 with its PCI companion chip, 3c905 nic, it8212 with two drives, and a random card DEC never released with a PCI-ISA southbridge chip on it |
| 01:44 | shesselba | At work I should be able to find some 3com NICs if you still need some replacements ;) |
| 01:45 | shesselba | or any Sun sparc you can think of ;) |
| 01:45 | _rmk_ | hopefully I'm going to be at the point in the near future where I can re-organize my entire network - I want to replace the firewall with a Thecus N2100 box I have here already prepared, which'll remove one of the last few remaining reasons for needing it |
| 01:46 | _rmk_ | the replacement box is already handling my incoming email, so I know that much works :) |
| 01:47 | shesselba | yeah, I guess that may be "some" mails per day ;) |
| 01:48 | _rmk_ | I keep finding reasons not to do the reorganisation, because I know its going to be non-trivial. |
| 01:49 | _rmk_ | and the cubox keeps distracting me too :) |
| 01:50 | shesselba | Ok, I prefer you not start reorganizing you network and stick with the cubox for a while :) |
| 01:51 | shesselba | BTW, Darren Etheridge asked me for TDA998x sync patches before I sent them to list.. then he reported still having issues with some modes (hsync inverted) |
| 01:51 | shesselba | I redid all the tests, everything is fine on cubox with your drm driver |
| 01:51 | shesselba | now Darren is looking into tilcdc and fixing sync ;) |
| 01:52 | _rmk_ | I suspect there's something screwy with his setup |
| 01:53 | _rmk_ | shame my omap4430 board doesn't have this chip on |
| 01:53 | shesselba | first he said, manually toggling tda998x sync registers fixes his horiz offset |
| 01:53 | shesselba | but the real issue is more likely to be in tilcdc |
| 01:55 | shesselba | I _know_ armada_drm sync is correct, I even measured front/back porch lengths for two or three modes ;) |
| 01:55 | shesselba | checked clock to data relation |
| 01:55 | shesselba | all the stuff you can think of |
| 02:04 | _rmk_ | I tend to want to get all video hardware behaving the same way on its outputs... none of this you connect a monitor to two different devices with supposedly the same video modes, only to find that the screen position is different... |
| 02:05 | _rmk_ | not a problem if you have a monitor connected to one machine, but put a kvm in there... |
| 02:06 | _rmk_ | anyway, zzz time for me |
| 02:06 | shesselba | I'd say, obey the EDID ;) |
| 02:06 | shesselba | yeah, me too |
| 02:06 | shesselba | n8 |
| 14:31 | _rmk_ | shesselba: have you ever tried accessing the DOVE_GLOBAL_CONFIG_1 register on the cubox? |
| 14:31 | _rmk_ | it makes mine hang solid, needing a power cycle to recover |
| 14:32 | _rmk_ | also tried the SSP registers around the same address (e8034) and that hangs the cubox too |
| 15:12 | _rmk_ | looks like anything in the f10eXXXX range hangs the cubox |
| 16:40 | rabeeh | _armk_: clock gated to that unit? |
| 16:40 | rabeeh | 0xf10exxxx is the ac97 controller |
| 16:41 | rabeeh | what does register 0x000D0038 show? |
| 16:43 | dbsx | If someone wants to add the recent chat on UBoot to http://www.solid-run.com/mw/index.php/Flashing_U-Boot please do. |
| 20:13 | shesselba | _rmk_: did you check the clock gates? does it solve hangs? I ve never taken care of updating non-DT in mainline, (a) because mainline CuBox is DT-only and (b) no one ever complained |
| 20:15 | _rmk_ | it seems to be - what it points out is that the drivers which touch that config register like pinmux need to ensure they get that clock... |
| 20:16 | shesselba | pinctrl-dove is taking care of it, arch/mach-dove/mpp might not |
| 20:18 | shesselba | There seems to be a _very_ limited number of people that use mainline Dove. There were only 2 non-DT board, a Marvell DB and Compulab CM-A510. I guess nobody has that DB, and Compulab seems dead to me. |
| 20:18 | shesselba | I am only using DT Dove and mainly work on it to get rid of non-DT |
| 20:19 | shesselba | DT will be kind of feature equivalent to _mainline_ non-DT dove with 3.11 which introduces irqchip, clocksource, and mv643xx_eth DT support |
| 20:20 | shesselba | IIRC pmu is missing |
| 20:21 | shesselba | and you know about hassles with DT and ASoC, DRM, media better than me |
| 20:21 | shesselba | but I count that as "future work" as there isn't even non-DT support for it in mainline kernel, yet |
| 21:43 | _rmk_ | yea, I need to get back to that ASoC stuff... |
| 21:44 | _rmk | 21:44 * _rmk_ remembers what he was doing a couple of hours ago... added your TDA998x patch to give it a go here |
| 21:44 | shesselba | _rmk_: you mean ranting at ASoC maintainers? ;) just kidding, with you complaining there is at least a chance the API improves here |
| 21:44 | _rmk_ | but never installed and rebooted the cubox |
| 21:44 | shesselba | great |
| 21:46 | shesselba | _rmk_: if you want to have a better impression of whether tda998x got the (input) image offsets right, set BLANKCOLOR to non 0 |
| 21:46 | shesselba | if input sync is wrong you will see non-black lines at the border |
| 21:51 | _rmk_ | tv really doesn't like it |
| 21:52 | shesselba | the patch? |
| 21:57 | _rmk_ | I think so |
| 21:57 | shesselba | dammit |
| 21:58 | shesselba | what mode are you using? |
| 21:58 | shesselba | and what do you see? |
| 21:59 | _rmk_ | that's 1280x720p60 |
| 22:00 | shesselba | and it comes from TV's EDID? |
| 22:00 | _rmk_ | yep |