01:10 <brads> Xogium: been lacking time of late by im not far from testing multiple types of emmc with C2 on 5.0.2. I had no issues with 5.0-rc6 but others have reported issues (particulary with arch linux)

01:11 <Xogium> brads: ah, well good to know I guess since I'm on arch

01:12 <Xogium> my eMMC is the black one

01:12 <Xogium> so I think samsung

01:12 <brads> ok I have both orange and back emmc's to try. I will make an effort to try this later today

01:13 <Xogium> one of those that had problem and on which I had to reduce the frequency to 100000000 instead of 200000000

01:13 <brads> Did that resolve the problem?

01:13 <Xogium> yeah, back then it stopped corrupting the card

01:13 <Xogium> I always left it at that speed since

01:13 <brads> OK no worries, I will do some full tests after work tonight

01:14 <Xogium> not to mention that its also in upstream now iirc

09:12 <jbrunet> MMC needs some work. I'm currently discussing the topic with amlogic but there is a lot of tests to do and takes time. Please be patient

09:15 <Xogium> jbrunet: sure thing :) I figured I'd ask before doing anything

16:45 <ldevulder> narmstrong, hi! I have some time to do some tests with vim2, I activated the SPI-NOR and "burn" u-boot.bin on it and I will want to boot from SPI. I know that the khadas u-boot version uses "kbi" command to do this. It's simply a 'i2c' command wrapper, so I activated MESON_I2C and tried to do the same command: 'i2c mw 0x18 x20 0 1' but this doesn't work

16:45 <ldevulder> have you been able to boot from SPI on this SoC?

16:47 <narmstrong> ldevulder: no, I haven't got time for thi...

16:48 <narmstrong> ldevulder: i'm glad you are trying ! Yep the kbi is just a wrapper

16:48 <narmstrong> but it could be porter to u-boot upstream

16:48 <narmstrong> *ported

16:48 <ldevulder> narmstrong, yes, easily I think, and I saw that khadas team does a version for rk3390 on a recent u-boot

16:49 <narmstrong> ldevulder: would be great if you can enable it, so we can do true EBBR/EFI on the vim2 aswell

16:49 <ldevulder> but as the i2c command fails I 'm not quite confident :) maybe some code in meson-i2c will need some change, I will try to investigate (but that could be like the USB issue on s912, still no idea...)

16:49 <ldevulder> narmstrong, I will try :)

16:50 <ldevulder> next challenge :-p

18:13 <ndufresne> chewitt, btw, build worked, but failed at very last step, trying to mkdir /flash and mounting it, not sure if this was suppose to be run as root or something

18:15 <chewitt> hmm odd

18:15 <chewitt> what distro are you building on?

18:15 <chewitt> we never build as root

18:16 <chewitt> we build all our official images on Ubuntu LTS releases, either 16.04 or 18.04

18:16 <chewitt> other things should also work, but Ubuntu appears to be the n00b builders go-to distro so we use the same to minimise differences

18:19 <ndufresne> Fedora 29

18:19 <ndufresne> basically it ends on a permission denied

18:19 <ndufresne> chewitt, do you have a variable to make the makefile verbose ?

18:20 <ndufresne> I tried V=1, that wasn't it

18:20 <chewitt> this is the bit at the end where it creates the squashfs files and then the .img ?

18:21 <chewitt> "image: creating file LibreELEC-Khadas_VIM.arm-9.1.0.img..." etc.

18:21 <chewitt> can you paste the output .. pastebin or spam me on PM

18:24 <ndufresne> give me a minute, I was doing this at home

18:25 <chewitt> no rush

18:29 <ndufresne> chewitt, that's how it fails, https://paste.fedoraproject.org/paste/mw3WgJSBOhbqz7cl-Tl1fA

18:32 <chewitt> cp projects/Amlogic/devices/Khadas_VIM/bootloader/release projects/Amlogic/devices/Nexbox_A1/bootloader/release

18:33 <chewitt> then re-run the build command

18:34 <chewitt> I think I built the Nexbox image once .. I don't have the hardware

18:34 <chewitt> so I didn't test/check the config for a while

18:35 <chewitt> my bad .. as usual :)

18:41 <ndufresne> running ...

19:01 <chewitt> all good?

19:04 <ndufresne> yep, just need to try it now ;-

19:04 <ndufresne> somewhere this week I suppose

19:08 <ndufresne> chewitt, were is the image exactly ?

19:08 <chewitt> target/

19:08 <chewitt> should have a .img or .img.gz file there

19:08 <chewitt> and maybe a .tar

19:08 <chewitt> .img = install

19:09 <ndufresne> good, got a cleanup that dir ;-P

19:09 <chewitt> .tar = update

19:09 <chewitt> technically you can update using .tar or .img or .img.gz files, but .tar is fastest

19:09 <chewitt> scp to /storage/.update on the box and reboot to update

19:10 <ndufresne> I voluntarily bricked the device so that it would pick the u-boot from my SDCard ;-P

19:10 <chewitt> not normally required

19:11 <chewitt> there's usually a reset button somewhere

19:11 <ndufresne> it's unrelated to LibreElec of course, the board came with q201 default configuration u-boot

19:11 <chewitt> hold that in, power on, wait for 3-5 secs and release the reset button

19:11 <ndufresne> which didn't have ethernet working

19:11 <ndufresne> ok, just like the android image

19:12 <ndufresne> anyway, for later, when I'm next to it

19:15 <ndufresne> chewitt, my goal is to check if a a properly patched kernel boots, and if by chance it works, also to give LibreELEC a try of course

19:15 <ndufresne> (well, on the last one, I could just test on PC, or on RPi)

19:16 <chewitt> mainline Amlogic still has some rough edges

19:16 <chewitt> but as long as you stick to 1080p media it's pretty decent

19:17 <ndufresne> noted

19:18 <chewitt> I've been using is exclusively at home since last November without any major issues

19:19 <chewitt> the occasional box freeze, but kids have learned where the reset buttons are :)

19:19 <ndufresne> nice

19:19 <chewitt> and I saw similar freezes on ye olde 3.14 images

19:20 <ndufresne> last time I was doing tests with GStreamer, I had specific patterns that would lead to freeze

19:21 <chewitt> the current ffmpeg v4l2 implementation needs to be reworked a little

19:21 <ndufresne> why so ?

19:21 <chewitt> we (royal) learned a bit from poking the stateless implementation for RK/Allwinner

19:22 <chewitt> and we need the same to move RPi towards vc4 .. which is planned for LE10

19:22 <chewitt> and the sooner we start some public testing of that stuff, the sooner we find bugs

19:23 <ndufresne> someone at RPi show me some work in progress V4L2 driver for the CODECs, prior to that there was DMABuf support for MMAL

19:23 <chewitt> we have a huge RPi userbase so it's something critical for us to get right

19:24 <chewitt> we have the basics working .. but lots of work to do

19:24 <ndufresne> the biggest tricky bit with v4l2 is to renegotiate the codec with a new resoltion

19:24 <ndufresne> and the seeking, where you keep flushing the codec to another IDR

19:25 <chewitt> seeking is one of the "needs improving" bits of the current Amlogic image

19:25 <ndufresne> yes I know, but it works a bit, in contrast to resolution changes

19:25 <chewitt> it works, but it's not robust enough, it's pretty simple to lock things up

19:25 <ndufresne> the second hardest part is to deal with stride and padding adaption between drivers

19:26 <ndufresne> that's were you start implementing G/S_ELECTION, so that you have a compose rectangle and an padded rectangle

19:27 <ndufresne> but then you app need to deal with figuring out (when possible) the display or color converter requirement

19:28 <ndufresne> you can always solve it the Android it, and just have a map of the requirement for your specific HW (GRAlloc), not something I can do in gst though

19:31 <chewitt> ^ all sounds greek to me :)

19:32 <chewitt> I focus on the packaging stuff .. you wouldn't want to run the code I write

20:22 <xdarklight> ccaione: when I try to edit the wiki (linux-meson.com) I'm being redirected to https://www.netsons.com/403/ after submitting my changes

20:23 <xdarklight> ccaione: is it possible to add https to the wiki? Chrome complains that logging into pages using http is not secure