Posts by buzzmarshall

i seen the Khadas EDGE write ups and stuff but didn't think it was available yet or is there someplace to actually get one?

ya i kinda noticed that as well but i am sure given time that can be cured as my interest in the chipset goes beyond the H94 type of tv box so i will probably disappear again and put some serious time into working into getting some form of kernel 5 series working for what i want to do with the board

i ordered a Rock64 Pro with 4 gig and the sata extension board along with the wifi board so hopefully it don't take to long as i known the asian new years stuff is gonna be upon us.... friggen canadian dealer in montreal wants close to double the price so i just ordered it else where.

i thru together another workstation last nite and started migrating the rockchip repos and toolchain stuff onto it and started looking at the panfrost stuff and ayufan's github as well... been putting together some of Arm's Mali stuff as well.

Kodi on a full Linux install is either x11 or wayland depending on your compile choice but essentially Kodi is just another app sitting in a window that the already running server is providing. With the stripped down linux versions you see things like LibreELEC running on i think your probably running into issue with LibreELEC is not really a true server/client like a full blown install. instead you've kinda got a busy-box install with all the graphics extentions added to it for the hardware your installing and running on and Kodi itself is tightly intertwined in all the service startups and other stuff thats its hard to separate some things without heavily modifying some things which kinda defeat the whole intended idea behind LibreELEC and how its structure is laid out. I understand your interest in what you suggest but i think for the LibreELEC type of projects its just not the direction that their agenda is based on. Its been awhile but i used to use x11 on the boxes when running Jtag and other debug software while dumping cores and checking registers within the SoC and i had to setup kodi in a more real linux install to make it work, so i feel your pain.

As some others have said tho for it be done properly so it works within the pervue of something like LibreELEC it really needs to be handled by the Kodi guys and good luck getting them to do anything outside whatever their direction is at any given time as there is always so much social drama between some of them its not even worth bring up. If its important to you then its something that i think you will have to take the bull by the horns and wrangle that one on your own. Years ago there were a few threads over on Freaktab by a couple of guys working at this but they eventually moved the group of them off to a IRC channel and i am not sure where it ended and that channel is now gone but who knows they may have just moved as theres always a ton of stuff going on in IRC at any given point in time, there and the news feeds (uucp). I don't have the time to go back and look at the subject anymore as all my S812's are fully supported and the only time i revisit them these days is to recompile and install the newest kodi versions. The other suggestion i would make is rather then going for a full blown current level browser if your just looking for basic surfing ability would be to find a simpler open source linux browser and start there.

I understand the neutrality of your position as i realize your driving force is to get the LibreELEC project better supported looking forward to ensure its own longevity. Others going back to the 1st boxes at a time when there was no OpenELEC's or forks who were trying to put Linux on a box were basically told to by Amlogic reps to buzz off as there was no interest in the subject. Even a few factory techs back then while working for major downstream factory had the door slammed shut when they attempted to show there was a developing market interest in Linux. Thank god most hackers never give up and eventually things started to appear and continue to appear while growing. Eventually Amlogic partially caved and put up a server for openlinux support but theres really not much of any real value on it and its old but a choosen few were allowed access or shared some info with while the rest had to hone the hacking skills and invade the asian factories looking for protected or leaked docs. Here it is years and millions of boxes later and its still pretty much the same.

After about a year of not really bothering with whats out in the public i started looking around while playing catchup and found this place to be a good place to read and chat and was nicely suprised to see at least Rockchips attitude has somewhat changed. From what i currently see at least Rockchip is openly providing decent information and not just to the choosen few but anyone that wants to download it which proves to me that Rockchip is light years ahead in at least providing some basic help and info, so on that point i guess you and i will have to agree to disagree.

Lets not be naive as we all know money makes the world go around and neither one of these billion dollar company's give much away for free, At least Rockchip has proven its helping no matter what the skill set is of anyone wanting to mess with their products while Amlogic is still sitting behind controlled access providing very little, When the reality is both of these billion dollar companies are trying to hedge their bet for the future by leveraging against the growing group of FREE smart coders that are interested in helping because of a willingness to want to help for a variety of well meaning reasons. Going forward both companies are going to need better Linux support as that part of the market develops and you can see it already in their opening up to fuel the much smaller manufactured products not coming out of one of their bread and butter mainstream factories. So why not leverage development time against the free labor pool i get it and really have no issue with it as thats the way the world now works but come on Amlogic at least open up the vaults and provide some basic docs.

As i said at the top tho, i understand your position based on the LibreELEC project which is community driven and depends on better support going into the future. I respect your thoughts and hopefully nothing i have said offends anyone as i always look at things from the big picture.

Quote from chewitt

It means right now we are focussed on core video/audio support more than figuring out some of the packaging mess required for WiFi/BT firmware and nvram files. It's something we need to align for Allwinner, Amlogic and Rockchip.

RockPro64 is a popular RK3399 board among a variety of RK developers.

k... i was looking at that and wondering... I need something to setup a working jtag and some other interfaces on and a open form factor like that is probably easier to retrofit then destroying the H96.

the reasons i ask about the linux and driver stuff is my intention is to try and do the same thing we did with the S812 in creating all the missing stuff to get it up and into Amlogics own 4.9 open linux. I was going to start on the S912's but since looking around here and reading have come to the conclusion of going back to Rockchip as they seem more open with support then Amlogic ever will be. Its a lot of work and a fair bit of reverse engineering to gain the knowledge of how things work but the RK3399 seems like a neat SoC and my interests in it actually go outside just another tv box and i would need to tackle some issues for that to happen anyways so i think its were i will dig in and start. thanx tho as i always find your posts interesting and informative

Quote from chewitt

LE has zero interest in supporting X11 on ARM hardware. In fact we're going to remove X11 from x86/64 hardware in the future too (which kills the current browser support there). So the remaining approach/solution which also works today is to run a browser like Chrome via docker. In essence you're going to run some kind of desktop distro (with X11 and the stuff it depends upon) in a container in the background. That probably doesn't do any favours for performance, but you get a working browser.

Before you ask, there is no nicely typed up guide on how to run a browser in a container. It's been done before though.

I realized based on your origins from OpenELEC that there was no interest in any thing like that and since you guys started LibreELEC which i think was a great idea as OpenELEC became more routed in the WeTek product it was nice to see this place really take off and even inspire others like CoreELEC.

my comments were more routed in the back and forth banter between a couple of the posters over what can or can't be done when the reality is whatever directions things go here is up to what you guys want to support, irrelevant of the reasons why one way or another. posts like that over technical issues make me want to point out that really no one is right or wrong as its a moot point.

I also realize that sites like this attract a lot of people looking for information and some will have other ideas on things and coming to site like here is a good start to see whats going on and its easy for things outside the interests of the project coders and owner to come up.

I think over time as you guys have excelled at moving forward theres so many things the project now supports that people start to expect other things that really are of as you say no interest to the ones running the show here, which is cool...

I'm glad you chimed in and clarified the goals and forward looking intentions tho, it makes it easier for guys like me to know what not to waste your time on which is one of the reasons i recently crawled out of the hole to see what others are up to as an example i have aware of all the S912 issues since the SoC was introduced years ago when i got a sample from a factory, but by that time a few of us had already had to tackle all the issues with the S812's we were using at that point, and for me its been great coming here and seeing yours and others feedback on the current state of whats being worked on. Ive been off the planet for awhile and your info on Panfrost has been great and appreciated.

In the end tho i agree with the sentiment if you want a browser then either stick with the native Android that comes on the box or install a fuller set of linux support then a basic busybox on steriods with graphics... lol

k... whats the issue tho with the WiFi and BT support and the mainline kernel switch... you kind of lost me there... you meaning that when the box switches to mainline kernel then things will be fixed? I kinda figured you would be fishing the hardware information from the intended OS in Android in this case so i am all good with that.

how bout the boot/reset vector on the box? by that i mean are they protecting that in anyway or can you adapt something like u-boot to just pick up the reset vector on the boot core and then pull the whole system up on Linux in this case and just do away with Android totally?

To be honest... its not that it Can't be done, its more of a matter of finding enough of the right people to take a interest and give up their time to cross and fix all the bridges involved.

I hate the word "can't" its just easier for some to use it because its beyond their own abilities.(not meaning that in a negative way) but my thinking has always been that if a person or group of people make something then someone else can always come along and make it do things it wasn't intended to do. In fact the firmware that this site was built to support and cultivate is based on that premise supporting Linux and a box that the manufacturer never originally intended it to be. Even Googles Android OS is a touch screen OS that until some smart none-google coders created and got working a remote control that enabled the reality of a box outputting to a tv as a usable appliance. Up tile that point most other methods of doing that were proprietary and not Android.

They need to strike the word Can't from the dictionary.

People have managed to get working browsers on boxes like this but it requires a fair amount of work to be done that is outside the whole premise of a stripped down Linux platform basically built to run Kodi. For the ones i know it was a personal or pet project that never went any further then the people involved. There is tons of private guys and groups constantly playing and creating things that never appear in the public and in a lot of cases its like that because the ones involved don't have the time or want the headache of dealing with the public and the stuff that goes with that part. Anyone thats been around long enough to go back to the days of XBMP and moving forward thru XBMC to Kodi know the social time and good and bad that lead to pretty much all of the original guys being gone because they had other things to do.

just my 2 cents on the word "CAN'T" haha

I have a H96 Max coming from the factory and should be here soon but the deeper i get into looking at the 3399 i am curious to if you guys have a better recommended different form factor board based more as a development board where more of the gpio's are exposed?

Something along the lines of a beaglebone or raspberry layout. been looking around seen a few different ones. things like the Rock64 and some other Pine made boards.

Its kinda a shame for me to wreck the H96 Max jury rigging it with interfaces where as a different form of the board. I need to get Jtag up and running on the cores to see whats going on in some areas...

Any suggestions would be appreciated.

Actually that is a good question and someone with more experience on the platform can provide a exact answer...

So far from the as i start to go thru the SoC's docs i see they keep saying up to 10-bit but so far in what little i have gotten into i have not come across the specifics of how it works. The Rk3399 looks interesting especially the idea of coupling i higher performance A72 cores and the A53 cores on the SoC.

Hopefully someone in the know will provide a better answer and i definitely agree i can see a bright future with this board.

Quote from chewitt

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

Quote from Kwiboo

RK3399 in mainline linux is rather good as it is also used in some Chromebooks (OP1 processor = RK3399).

When it comes to the 4.4 kernel rockchip have a pretty recent Linaro Stable Kernel (Android) merged, unfortunately when I asked if there was a change to see a new version pushed to github it ended with "not a chance", I am speculating that the internal rockchip linux tree contains code for unreleased products blocking pushing a new version.

For LE we use a special 4.4 version that I have tuned for video/audio/cec/media, see the different rockchip-4.4 branches at Branches · Kwiboo/linux-rockchip · GitHub, they correspond to the patches seen at rockchip-4.4, the base version used in LE corresponds to the release-4.4 branch in my kernel tree.

Moving forward I am mainly focused on mainline linux development (rk3288 and rk3328 already works rather okay), my next step is to confirm rk3399 devices works before I push initial mainline support to LE.

As mo123 mentions gpu driver exists for T860, you can find it at GitHub - rockchip-linux/libmali: The Mali GPU library used in Rockchip Platform, for LE we only use the gbm version.

When it comes to tv boxes I would also highly recommend any of the SBC type of devices, box devices will not see much support when we move to mainline unless vendor or other community members upstream device tree to mainline u-boot/linux.

Display More

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

Quote from chewitt

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