ok so much of this is in the upcoming update, we made a snap decision to go to taiwan because of the 30 limit on the china dual-entry visas. i'm staying with a friend who has a stack of equipment including IR oven, small pick-and-place machine, scope etc. so it's a much easier arrangement, i'm helping him out as well.
the rk3288 board is going to first prototyping, we're getting quotations from PCB manufacturers. that leaves me free to move to the next PCB design, and i picked the passthrough card... which turns out to be much more complicated than i was expecting. i _could_ do a simple version (just a TFP401a) but it would have to have 2 USB ports and a break-out arrangement for the remaining pins.... i decided instead to wire them all to a STM32F072.
now, the idea here is to pre-load a userspace USB-based DFU bootloader into the NAND flash, and to require firmware to be uploaded after it reports the contents of the EOMA68 EEPROM ID. the TFP401a's I2C will be connected to the STM32F072, it can emulate an EEPROM and can load EDID data which tells the TFP401a what the LCD's resolution is.
normally the LCD resolution would be fixed... but here it is not possible to know what the LCD resolution is going to be.... also we have no idea in advance what the various functions are of the EOMA68 pins: maybe the SD/MMC pins are used for an SD card (in which case the STM32F072 can be programmed to be a USB mass-storage device), but maybe they are used as GPIO, or maybe they are used for a WIFI SIP module: we just don't know. hence the need to be flexible and for firmware to be uploaded on a per-boot basis.
i would _like_ to use a more powerful EC but i haven't the time to learn a new EC... so the STM32F072 it is.
l.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Hi. I have a CRT monitor from 2002 and it is my only monitor. Are these monitors supported by EOMA68-A20?
If you remember CRT monitors, they physically update the screen and 60 hz refresh rate is extremely harmful to the eyes because you see flicker. My monitor runs at 85hz refresh rate. The problem is that most today's monitors are pretty much hardcoded to 60 hz and it's not easy to change it.
I connect 2 desktops to this monitor. 1st one has GeForce 4 Ti GPU (2005) and 2nd one has Radeon HD 5850 (2011). Both computers report that there's no EDID. However, GeForce card correctly finds the maximum resolution (1600x1200@60hz) and uses it in GRUB, Radeon uses 1024x768@60hz.
I was able to make a script that sets my preferred resolution (1024x768@85hz):
xrandr --newmode "1024x768_85.00" 94.50 1024 1096 1200 1376 768 771 775 809 -hsync +vsync xrandr --verbose --addmode DVI-1 "1024x768_85.00" xrandr --output DVI-1 --mode "1024x768_85.00"
However, it only works with Geforce and the only way to make it work with Radeon is to install proprietary firmware and free driver. Proprietary driver or no firmware don't work.
I wonder, does EOMA68-A20 support these commands, especially without proprietary firmware for it's Mali GPU?
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Dec 26, 2016 at 9:24 PM, FaTony fatony@fatony.net wrote:
I wonder, does EOMA68-A20 support these commands, especially without proprietary firmware for it's Mali GPU?
for its MALI GPU, not "for it is MALI GPU".
basically: i don't know, but it's easy for you to find out. it's an A20 processor. if you can find the answer on the general internet about any device with an A20 processor, then that's the answer. there's nothing special about the EOMA68-A20 Card's A20 processor, nor anything else additional, specific or restrictive or different in any way compared to any other device using the A20.
so, you could ask on the linux-sunxi forums for example.
l.
I wonder, does EOMA68-A20 support these commands, especially without proprietary firmware for it's Mali GPU?
This has nothing to do with MALI: a GPU is a (co)processor which lets you do computations often useful for graphics (but nowadays also used for other things), so it is usually wired such that it can write directly onto the framebuffer memory.
But the GPU itself sees the framebuffer as some chunk of memory, writes to it, and that's it. It has nothing to do with bringing this chunk of memory to an LCD or some other display, which is instead done by some other circuitry (called the "display engine" (DE) on the A20). The same goes for the video-decode accelerator (aka VPU), which is usually also a completely independent piece of hardware, BTW, which also just writes to the framebuffer.
In the x86 world, since the graphics cards include both the GPU, the VPU, and the "display engine", those notions are usually conflated, but technically, they are independent, and in the ARM world they tend to be clearly separate.
So, the question in your case is if the DE can handle your timings and if the `xrandr` thingy will be able to properly configure the hardware. AFAIK the A20's hardware should have no trouble with a 1600x1200x85Hz timing, so the question is more on the software side.
For the "vanilla" kernels, I know there's some "sunxi-drm" module available (tho AFAIK it still hasn't been merged into Linus's tree), so some of the infrastructure is available but you still need an Xorg server on top (presumably the `modesetting` driver might do the trick).
Stefan
http://rhombus-tech.net/community_ideas/passthrough_card/
quick update of the passthrough card page, revision 0.10 layout is almost done and will be sent off for PCB (4 layer) manufacturing soon.
l.
arm-netbook@lists.phcomp.co.uk
-
FaTony -
Luke Kenneth Casson Leighton -
Stefan Monnier