<hanetzer>
yo. someone suggest a good rk3288 or better dev board with full jtag support?
nighty- has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
<beeble>
hanetzer: jtag is muxed on the sd card pins on most boards. so any should work for you with a breakout board for an existing swd jtag device you have.
<beeble>
ok mixed jtag and swd in a sloppy way
<hanetzer>
beeble: oh nifty. don't suppose you could suggest one?
lurchi__ has quit [Ping timeout: 268 seconds]
<hanetzer>
also, regarding the mali in the rk3288; can it be used for av encoding/decoding like one could with a 'normal' desktop gpu?
<beeble>
do you have a swd capable debugger?
<beeble>
an openocd bitbang device for example
<hanetzer>
beeble: I have a flyswatter2 and am willing to acquire another device if needed :)
<eballetbo>
In the documentation point to a non-existent file include/dt-bindings/clock/ddr.h
<eballetbo>
Anyone can explain me what exactly is this parameter and where I can find more information?
<eballetbo>
kever maybe? ^
<beeble>
eballetbo: i can't say anything about the missing ddr.h but for speed bins take a look at JESD79-3F page 157
chewitt has quit [Quit: Adios!]
<hanetzer>
would be really nice to get this grub2 as a coreboot payload working for my chromebook :P
<Ke>
would be awesome indeed
<eballetbo>
beeble: thanks, so if I understand correctly a rockchip,dram_speed_bin = <21> is DDR3-1066F (7-7-7)
<hanetzer>
Ke: doing a slight bit of experimentation with it.
<beeble>
eballetbo: that may be soc dependent? but not sure
<hanetzer>
eballetbo: looking at the commit that introduced it, no such file was added
nighty- has quit [Quit: Disappears in a puff of smoke]
<eballetbo>
hanetzer: yeah, that's why I was asking
<eballetbo>
beeble: I suppose is both, dram and soc dependent? I mean one dram can support highest speed than the soc supports, in this case we just run dram slower than is able to do.
<beeble>
eballetbo: i meant what <21> means.
<beeble>
because thats DRAM3_DEFAULT in that driver and i think thats soc dependent. but only skimmed the driver
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
JohnDoe3 has quit [Read error: Connection reset by peer]
JohnDoe3 has joined #linux-rockchip
<mmind00>
beeble eballetbo: but then again, it looks like an oversight that this got into a binding at all ... i.e. dt-binding should be descriptive (like having a real unit of sorts) and not contain hw-specific magic values
<beeble>
mmind00: agree
panicking has joined #linux-rockchip
kever has quit [Ping timeout: 240 seconds]
kever has joined #linux-rockchip
nighty- has joined #linux-rockchip
afaerber has quit [Remote host closed the connection]
kever has quit [Ping timeout: 256 seconds]
stdint has quit [Ping timeout: 276 seconds]
stdint has joined #linux-rockchip
Aussie_matt has joined #linux-rockchip
<eballetbo>
mmind00: horrible mistake, sorry, answered your email ;)
BenG83 has joined #linux-rockchip
<eballetbo>
I am still learning about all this stuff
<Ke>
hanetzer: how far along are you, perhaps you could even share the magic of the rom layout?
<Ke>
hanetzer: I might even lie that I could help you
<hanetzer>
Ke: there is no magick to the rom layout. just clone coreboot, menuconfig it to do veyron jerry, and feed it a self-made grub standalone image from git
<Ke>
hmm, I don't have to preserve anything in the rom?
<Ke>
also, I have Kevin, wonder if there is a difference
<hanetzer>
nope. though I do suggest a backup. and what you see in the imgur link is what you get. doesn't get further than that.
<hanetzer>
no keyboard input, internal or external.
<hanetzer>
is kevin a veyron ?
<Ke>
rk3399
<Ke>
I have veyron-speedy as well
<hanetzer>
unsure if rk3399 is 'supported' at all.
<hanetzer>
2gb or 4gb ram variant?
<Ke>
supported where?
<hanetzer>
in grub2
<Ke>
4GB both
<Ke>
I thought grub uses EFI or something?
<hanetzer>
ah. well, apparently the work I've done in u-boot works on the 2gb veyron speedy, but not the 4gb
<hanetzer>
it can, but this is grub as a coreboot payload, different rules :)
<Ke>
any idea, what's wrong with the 4G version
<hanetzer>
ddr init
<Ke>
though I might not be that much into throwing additional effort to speedy anymore, as I am planning to move to aarch64
<Ke>
but I should learn to disable the beep there also
<hanetzer>
nifty. don't suppose you know anyone really handy with soldering in texas? I need a tiny, very fine header put on to my speedy
<Ke>
no
<hanetzer>
if I had this header, I could prolly do a bit more good work to get something working to let you use 'normal' linux normally
<Ke>
my local soldering child labour is leaving the company, so I am going to have trouble with that as well
<hanetzer>
haha
<Ke>
luckily he actually taught me most of the basics already
<hanetzer>
I'm alright with the basics. some smd, lotta through-hole. but this is a very dickish part
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-rockchip
<hanetzer>
Ke: can you get me cbmem -c | grep -i ram from your speedy ?
Aussie_matt has quit [Remote host closed the connection]
<matwey>
I see the following error when run the command: mpi: mpp version: Without VCS, under bleeding [h264_rkmpp @ 0x7f7006f640] Decoder noticed an info change (854x480), format=0 Impossible to convert between the formats supported by the filter 'ffplay_buffer' and the filter 'auto_scaler_0'
<matwey>
How could I run ffplay with hardware h264 decoding?
<Ke>
in general h264 is a family of codecs, perhaps that one is just not supported?
<ayaka>
matwey, the problem is that, the video change its resolution
<ayaka>
the gstreamer can handle it as the products request it
<ayaka>
but ffmpeg is not supported official
<matwey>
ayaka: is resolution rescaling handled at hardware too?
<hanetzer>
is there a way to get a shell over the otg port on rk3288 hardware?
<ayaka>
matwey, no, but its the video stream that change its resolution
<ayaka>
the hardware decoder don't care about it, but it would notify the external application
<matwey>
It is just test file from Big Buck Bunny. Should I try another h264 video?
<ayaka>
yes, you should
<matwey>
Hm, sintel-1024-surround.mp4 shows the same behaviour
<ayaka>
ok it seems that you didn't use the drm overlay
<matwey>
How could I use it?
<ayaka>
I don't know
<matwey>
What is the general difference between ffmpeg and ffplay?