06:52 <hexdump0815> some more info on the "missing memory" topic - this is from an s905x box with mainline (5.0.1 - another s905w box with the same kernel shows the same values):

06:53 <hexdump0815> Built 1 zonelists, mobility grouping on. Total pages: _220480_

06:54 <hexdump0815> Memory: 840128K/_896000K_ available (11068K kernel code, 1612K rwdata, 5304K rodata, 1408K init, 385K bss, 55872K reserved, 0K cma-reserved)

06:55 <hexdump0815> this is from android (3.14.29 kernel) running on the same s905x box:

06:55 <hexdump0815> Built 1 zonelists in Zone order, mobility grouping on. Total pages: _249203_

06:56 <hexdump0815> Memory: 550244K/_1010688K_ available (11014K kernel code, 1256K rwdata, 4192K rodata, 1343K init, 3796K bss, 460444K reserve)

06:56 <hexdump0815> and for comparision, this is from an s805 box running the same mainline kernel version (5.0.1):

06:57 <hexdump0815> Built 1 zonelists, mobility grouping on. Total pages: _259908_

06:57 <hexdump0815> Memory: 933928K/_1046528K_ available (12288K kernel code, 1642K rwdata, 4844K rodata, 2048K init, 404K bss, 47064K reserved, 65536K cma-reserved, 196608K highmem)

07:00 <hexdump0815> looks a bit like the s905x/s905w mainline kernels do not see or find all of the memory in the box - it sees/finds 100+mb less ... maybe someone else can check on other boards like gxbb or gxm?

07:03 <hexdump0815> the s905x/s905w android and the s805 mainline values look way more logical to me - anyone having any idea what is going on for gxl mainline here?

08:27 <narmstrong> Amlogic u-boot does wild stuff with memory reservation before loading u-boot, dump the memory zones when the kernel is running, not from the boot message

09:48 <hexdump0815> do you mean from /sys/kernel/debug/memblock/memory? there the picture is the same: it goes up to 0x0000000037ffffff, which is 896000K

10:03 <chewitt> hexdump0815: random Q .. are you using any of the patch-sets from my repo in your GXL image?

10:03 <chewitt> or default mainline?

10:23 <hexdump0815> chewitt: it is plain mainline 5.0.1 - i just wrote and ugly little script to sum together /sys/kernel/debug/memblock/memory (=896000K) and /sys/kernel/debug/reserved (=40460K)

10:28 <repk> kk/10

10:28 <repk> oups sry

10:33 <hexdump0815> so in general it looks like the memory values from the boot messages are ok - can maybe someone with mainline uboot check, if you see a larger difference between the memory seen by the kernel (barK in the boot message: Memory: fooK/barK) and the builtin memory of the system?

10:36 <hexdump0815> maybe this is related to the legacy uboot in the box (2015.01)

16:48 <marcodiego> chewitt, what is the status of the licence of https://github.com/LibreELEC/meson-firmware ?

16:49 <chewitt> marcodiego still not confirmed I think

16:49 <chewitt> the firmware files are extracted from GPLv2 sources (Amlogic's buildroot kernel)

16:50 <marcodiego> chewitt, any news, effort to get it opensourced? Hopes for the future? Where can I track it?

16:50 <chewitt> but AFAIK their legal people didn't clarify status yet

16:50 <marcodiego> chewitt, any reason why they don't release the source code?

16:50 <chewitt> hence the V4L2 vdec (which depends upon them) hasn't been merged upstream yet

16:51 <chewitt> the sources are public

16:51 <chewitt> but in the 3.14 kernel the firmware is embedded into code

16:51 <chewitt> in the V4L2 vdec the firmware is extracted to files

16:51 <marcodiego> hmmm

16:52 <chewitt> no idea what the hold-up is .. but .. lawyers :)

16:52 <marcodiego> it would be great to have it open-sourced. This would complete cedrus, amlogic and rockchip free codecs

16:53 <chewitt> I'm sure it will happen, but these things take time

16:53 <marcodiego> amlogic i too common on tv boxes, having it open-sourced would turn many of them into usable general purpose computers

16:53 <marcodiego> chewitt, hmmm... why are you "sure it will happen"?

16:54 <chewitt> conversations I've had with senior people at Amlogic

16:54 <marcodiego> hmmm cool

16:54 <chewitt> people stop short of making an actual commitment .. but the intent is there

16:55 <marcodiego> I'm happy to know this will happen then

16:55 <chewitt> and there are some commercial things afoot in the Amlogic ecosystem that will require it

16:55 <marcodiego> just sad by not knowing how long it will take

17:02 <marcodiego> thanks for the info!

17:05 <chewitt> I wish I had more

17:06 <marcodiego> thanks anyway. This is something I was really wanting to know. Where can I check the source code of the firmwares? How can someone compile it?

17:12 <chewitt> download sources from Amlogic's 'openlinux' server

17:12 <chewitt> look in kernel/aml-3.14/drivers/amlogic/amports/arch/ucode/

17:13 <marcodiego> thanks!

18:56 <Darkmatter66> chewitt, I think the requirement to merge the vdec driver upstream is to simply have the firmware files easily downloadable on amlogic website with a statement that these files can be used freely by the anyone, so they don't have to open source the blobs, just state that it can be freely used

18:56 <Darkmatter66> chewitt, I read that somewhere but maybe I'm mistaken

18:57 <Darkmatter66> chewitt, I don't see how that's very difficult to do, or how does it harm their technology by simply providing closed source blobs