Posts by buzzmarshall

    u-boot stores the MAC in efuse and the kernel reads the values back from efuse

    i understand that but even still after the system is up and running the ifconfig command will let the system spoof the stored Mac till the next reboot, thats kinda why i use the autostart script. I know i just checked one of your current builds on the generical S912 project and i can ssh into the box and issue a ifconfig command and alter both the wlan0 and eth0 Mac Address with no problems...

    actually now im just more interested in why his script does not seem to work... lol

    I can't answer for how datrh has it setup but typically you don't set the Mac Address in the device database files, tho over the years i have seen people try and push it via the dtb. Normally the dtb provides hardware settings like memory address's and control register parameters so that the on board hardware gets picked up by the kernel.

    Usually things like the Mac Address gets reported by the firmware on the device once the kernel knows what and were the device is. Its strange that the autostart script is not overiding the detected Mac with the one you put in the script. Ifconfig is just a standard linux network command that can be run from a terminal at any point in time once the box has booted up and is running. Logically speaking if the scripts not setting it to what you want there must be something else messing with it after everything is up and running. Its either that of for some reason something in the firmware build is preventing the script from being picked up and run. I just checked the most recent LibreELEC and CoreELEC S912 builds i test on a bunch of Sunvell boxes and the script works fine on both systems.

    Hopefully datrh will have some ideas for you

    Thanx man... you answered quite a bit for me in that... i had already downloaded most of that and seen the different branches on some of it and was kinda wondering about them so your post helps a lot on what i seen and cloned. I just need to build something to get familiar with their build methods.

    as well i seen the trusted platform repo and was beginning to wonder about locked stuff.

    once again thanx guy

    In the mid-term the difference between T860 (RK3399) and T820 (S912) should become moot because both will be using panfrost. The current advantage of RK3399 is that the T860 blob is available publicly and it's the more stable option, and we can elect when to make the change vs. S912 which can only use panfrost. Fortunately panfrost is making rapid progress :)

    Ya i have been paying more attention to Panfrost since you mentioned that before and your right it doe's look promising, i've cloned the repos and been looking at things and can see its promising

    Ive got most of the Mali docs and tools and kinda thought they looked pretty close but just wasn't sure of the issues of public support , but i was nicely surprised to see Rockchip openly supporting linux. I started on Rockchip way back so i am somewhat familiar with them but i moved to Amlogic which was a good thing for me for along time but now have come to the conclusion its time to change to something again and Rockchip looks extremely interesting to me.

    cool... thanx... i have kinda watched the armbian thing for quite awhile so i am somewhat familiar what they were up to.

    ya the RK3399 is where i want to start and look, As far as anyone else software that i am not really to worried about as i have been building embedded linux systems for a long time. I am interested because i want the 4gig of ram which will let me do more on the box. I was aware of the lack of CEC support but just wasn't sure about the Mali Cores. The T820/830 i am already well familiar with and aware of the issues with it out in the public

    I realize now after being away from the scene for awhile that things really haven't changed all that much with the S912's and Amlogic providing any real support as they seem to be relying on the community and a private company to get things in order. Its nice to see that a couple of good hearted coders at least got things going some what by using the Hybris library as a layer to handle allowing the Android blobs to run giving at least a somewhat workable solution but now after a week of reading and playing catch-up i realize that most things are still stuck at a community participation level. especially the mainstream kernel stuff. I can't belive they have not made any real headway on that. Privately theres a set of patches that have been developed to unifiy the S8xx and S9xx to their own 4.9 outta tree level and from there another set of patches to bring things up to 4.19 mainstream. Just the patches have never been publicly released.

    Anyways i digress...

    thanx for the heads up and information

    I am curious with regards to some of the status and issues of running linux on the RK3399 platform.

    Its been along time since i last played with developing on Rockchip (back in the rk3066 and rk3188 days) and i can see the linux platform is sitting around 4.4 and i am curious as to whether those builds are out of tree builds or are they in sync with the main line 4.4 kernel tree.

    As well i am interesting to know if the Mali T860 processor used in the RK3399 is in a simular position as the unsupported stage the S912's Mali T820 is stuck at?

    I have a H96 Max on its way from a factory and am planning on migrating my own operating system over to a Rockchip platform (its basically a similar idea as LibreELEC just i started it before LibreELEC existed when all that was around was OpenELEC} I am not interested in even having Android on the box so that part i don't really care about.

    Basically i am just trying to see where the Rockchip platform sits reqarding a linux system and from downloading all of the Rockchip SDK's and some other githubs curious as to where things sit as they seem to be providing more open support then Amlogic ever has and probably ever will.

    Anyways any thoughts or information on the status would be greatly appreciated.

    also i meant to add that if you follow the specs regarding media files and how they get packetized you will come to see that retention of a audio/video file on the local device may be as simple as the commands used by the particular application or script retrieving the remote file. a file open type call will treat the file differently the a file streaming open call. those aren't the real calls, just meant to show that the commands used to get the file and help decide the method of handling the file

    Anyways.. read what you posted in that information as it proves my point, as your still missing the idea of what data is being sent from one device to the other.

    One last attempt... for example: with any of those methods your referring to that doc explains it ...

    say im screen sharing on my phone and want to share that display on my tv so i open up a pdf on my phone and am reading it and cursoring thru the page, you will see the identical screen now shared on the casted to or mirrored to display. or say i am using a file browser to hunt for a file on my phone i will now see that as well on the shared display.. the data being sent to the mirrored or casted to display is not the same as a audio/video stream... ya i quess you could start a movie on the phone in full screen and you would see it on the other display but now while thats running move your cursor around the screen and you'll see it do the same thing on the screen... Now i am sure that if one were to look at the actual movie files data on the phone your not going to find that information of the cursor in the data contained in the movie's data, not even in the wrappers that handle the packets that create the stream.

    how anyone defines the word "Steaming" is really meaningless without understanding the data thats contained in the packetized data that creates a stream. and thats my point... as unless i misread your original inquiry about wanting to stream audio/video from your local network to your other devices which implies your wanting to stream a typical audio/video file... If you really want to understand more about streaming you should spend some time reading the DVB spec's as it covers most of the protocols and specs involved in transmitting media wether its from a sat's downstream or from internet feeds and cable's the information needs to be packetized and control via the accepted standards and understanding that may help your realize that just because something is sending wired or wireless information of any type to another device there has to be a spec or protocol to how that data is organized but not all things are the same.

    to most peoples mindset Streaming implies a audio/video stream even tho something like your cell phone operates on sending and recieving data people really dont say they are streaming their phone calls.

    As i said i think your misunderstanding the term streaming and the technologies involved in how those devices you keep referring to work.

    I think you're intermixing the concepts of media data stream and mirroring or screen casting when they are really 2 different things.

    Streaming a media file requires a application or server daemon to handle streaming the file according to one of the accepted streaming protocols which means on top of some stream control code its also actually sending the audio/video data stream and theres no reason someone could not create or embed a daemon on LibreELEC to do that.

    Things like ezcast are mirroring the display data from one device to another display device or many devices. In other words its got a dongle on one end and another dongle at the other end that plugs into the hdmi input so that when you run the dongles application on the sending device it controls the hardware dongles that talk wirelessly to send the screen data from the sending device to the receiving device dongles. The wireless mirroring signal is not from what i understand the same as a media stream that is audio/video and my quess is that its probably proprietary to dongle manufacturer.

    TV's that play back media from a usb device plugged into it do so because the TV's firmware has some type of built in media player.

    Don't get me wrong as i am not saying you can't do something i am just not sure how to help as i think your mixing the concepts and its making it hard to give you the answer you expect.

    If you want to stream media then you need to setup something as a server to serve that data up to the network, and have it on some device such as a capable router or a NAS box.

    Someone please correct me if i am wrong but from what i understand about the Ezstream product thats how it works.

    just in case i made a bad assumption of your understanding, i realized i should have mentioned that the example i used was for a wired connection based on the eth0 device name i used in the script. but if your talking about a wireless connection being your issue you would need to change the script to apply the command to the wifi device which probably will be something like wlan0.

    if you can get to the boxes command line via ssh just issue the ifconfig command and it will report what libreelec sees as active interfaces and you can check to make sure of the proper device name to use in the script. theres no reason you cant put 2 lines in if you want to set (spoof) the Mac Address of both devices.

    Strange as that should work, I run about 6 identical boxes from the same factory i buy from and new out of the box they all have the same MAC so i use that script on each of the boxes by installing the script and then just changing the last byte of the Mac Address in the each of the boxes script and thats worked for years with no probs. To me what your describing makes me inclined to think that something further down the startup chain is setting the address... could be a plug-in of some type or some type of anonymizer or who knows but something definately adjusting it. Normally the network stack will sence the hardware's mac and use it until you some how tell it to be something else. I quess you could start by finding out what the hardware's real mac is and then once LibreELEC is up and running go look in the Info/Network panel on the LibreELEC settings addon and see what LibreELEC thinks it is. if there the same then it would appear LibreELEC is picking the network stack up ok and its something else you've got thats running and changing it.

    Hard to really say without more knowing more...

    As well depending on where your noticing the constantly changing address my help figure it out as well... meaning if your seeing the change happen on the box then its probably on the box but if your seeing the change further out on your network then maybe you've got something setup in your router thats spoofing the real Mac to your routers Mac for routing control or something along them lines.

    you can create a file called and place a line with

    ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx

    replace the xx's with your mac address you want to set the box to.

    put the file in the config directory and on rebooting the box that should set it to what ever you want.

    if you already have the file on the box just add the above line to the end of the file you've got.

    hm... not really anything i have ever messed with but my quess would be that to support something like Miracast it would be something that the underlying operating system kodi is running on wound need to support it, which is why Android probably works. Kodi basically is just another application that runs ontop of something else as a OS that would provide the hardware implimentation layer so in the case of something like LibreELEC or any of its forks my quess would be that the basic support would have to start there and then allow a running app such as Kodi to make calls to that layer thru a plugin coded up to handle that.

    I may be off base on what i have said but that would be my initial thoughts on the idea and if someone that knows more about the idea please feel free to correct me on the idea as i really have never messed with any of that. I just no basically Kodi inherits its hardware calls from the underlying OS which in this case would be what LibreELEC provides.

    To stream something in the manner your suggesting means that the box would have to have a streaming daemon of some type installed and running to handle the streaming of the media source on the usb/memory stick. I am not sure thats something available with LibreELEC as normally LibreELEC is handling Kodi which is really more like the client end. Some IPTV plugins i think may be able to somewhat do so because the plugin has the server end as well as the client end code in it. Theres plugins around that do have the ability but there not something i really ever mess with so i can't comment on that stuff.

    As far as recording a incoming stream and being able to save it, theres a few ways of handling that which can be by coding the plugin to retain the read ahead caches and rather then pitching the data save it by writing the data to a file. Another way could involve writing code that peels the transport stream packet wrapper off and as it does so fudge the control parameters to tell the receiving device to treat the file as a download so save it without trying to view it.

    Sorry i meant to say as well:

    That maybe if your playing around with dvb and satellite streams then maybe it might be something to consider but to be honest because i don't play with dvb thru this type of box others may have a better informed opinion on the subject. I do know from years of sat hacking that the dvb transport packets and how the system handles decoding (especially if theres a CA involved) may require or perform better with more Sram

    Being a long time xbmc / kodi developer as well as doing a lot of embedded controller development and reverse engineering over the years what my thoughts are would be this...

    Having more Sram is always a good thing and when the choice was 1 gig or 2 gig i always told people go with the 2 gig based on the facts that with Android running so much crap in the background and with Kodi evolving and requiring a bit more memory for running in that 2 gig was one way to help eliminate all the old random lockups back in the older dual core days. With the debate between 2 gig or 3 gig or even 4 gig i personally don't think its that much of a real issue anymore as 2gig is easily enough to run kodi even if it is still just another app running under Android and with things like LibreELEC should be plenty for sure. As far as bigger flash area i look at it from a cost point.

    Currently I think bigger amounts of Sram and Flash are being used by the marketers as really not much more then a way of trying to keep bringing to market new products, the few actual factories all sell oem and branded products and they all know that if things sit stagnate for to long the end users start to figure out just how many different brands and models are actually all the same other then things like cases and layouts so in between things like new Android versions they are all using the bigger Sram and Flash size as a method of recreating some perceived differences trying to gain a bigger part of the buying market.

    You can see what i am talking about in the box prices. i remember when the 1st 3gig and 4gig boxes came out and what the dealers wanted in a price increase for those few 1st boxes over the normal 2 gig boxes flooding the market at that time. The increase was huge when put into perspective to the real costs in both time and parts so for a short period of time the few dealers selling those boxes were doing much better in the market, now after a year or so pretty much everyone is up to the same point again. I develop and build a fair amount of embedded boards all the time and have a pretty good idea of cost and time so it was not all that hard to spot what was going on.

    Some will argue bigger is better while others say its negligible at best. Personally i look at it from a money point and tell people that if your buying a box thats got bigger on it because people are currently developing new software for that box and the price is not to bad then go for it. but if your just buying a box with bigger memory because some dealer says its better i would that unless your getting it for a real good price not to bother.

    Kodi runs great with 1 gig of sram on this type of hardware and if your running LibreELEC or one of its forks 2gig should easily perform well and even with rom games some methods treat the rom emulator as stand alone making Kodi release its sram till it starts back up so until things drastically change my approach is why bother.

    looks like they are making some good headway and making things more usable but "full media support" i think is still aways off. from what ive been reading trying to play catch up is mainline kernel support is getting much better but theres still a quite a bit of hardware support still missing and the level of trying to reverse engineer the userspace code is still going on.

    on another note: as I am gathering source code and information trying to come up to speed on the subject of getting Amlogic support into the main stream kernel i keep seeing or reading about this idea of Amlogic and Baylibre having formed some type of relationship making Baylibre responsible for Amlogics linux development and support which makes me wonder why anyone would have to reverse engineer anything as Amlogic could simply supply the required information. Even if there was a licencing problem between Amlogic and Arm over binaries and Amlogic making that availble to someone like Baylibre theres no reason why Amlogic cant release the technical specs on the SoC as that Amlogics stuff. Having the full docs and reference design materials would drastically speed up the development of open source common parts.

    anyways still reading and gleaning just something that makes me wonder as i catchup

    without further investigation its hard to say and probably best asked over on Kodi's site, but as far as the xbmc reference a lot of the current kodi building setup still refers to xbmc and not kode persay... usually in the build structure if they start disseminating between the terms xbmc is the call while its usually a link pointing to the kodi directory. so its maybe posible for some reason the softlink was removed someplace leaving you pointing to a xbmc reference that goes nowhere. the vacant repository unknown messages would lead me to think its something along them lines.

    but as suggested its probably to ask over there as i could be off base