Posts by buzzmarshall

    Ya i would agree that seems a bit weird to make a disclaimer like.

    without comparing the actual specs between the 2 to see the differences its hard to say but typically whenever i have seen disclaimers like that it usually equates to parts-supply chain stuff where depending on the availability of the part at that point in the production cycle maybe what they are talking about. that would be my quess.

    HK has been around longer and the likelyhood of diminishing software support is more of a worry with Khadas's products then a company like HK thats already established itself.

    I think Khadas is concentrating to much on the extraneous extra's market when really the bulk of their time should be spend on building and attracting better Software support at this point in the game. Ya i know HK sells extra's as well but they have been around longer and are much more settled in at the production level and development...

    Don't get me wrong as i am not saying Khada's products are not good its just they seem more focused on leveraging the various revenue streams leaving Core Software development to a very small group of coders. and based on the costs there is no way i would spend more on a Khadas board over a N2 at this point in time.

    I think currently Khada's position in the market really is just being pushed by a couple of individual's that for whatever reason seem to think they are superior to others when the reality is more based in who's getting the samples and whats expect of them. maybe down the road when Khada's support grows to include more then just a small group of dudes trying to support it that things will be better.

    To be honest if i was really looking for a S922 based box with anything to do with Dvb Streaming then i would be looking at the Dreambox One as its got the horsepower and resources to hardware handle a dvb transport stream properly and do all the processing that needs to be done.

    I am at this point tho unaware of anyone thats released LibreElec for it. tho i do know its been hacked to run Kodi.

    You may want to check and make sure your naming conventions for the stuff in the libraries/databases are in a consistent style compatible with the kodi version.

    Ive got over 4000 items in my move/tv database and always had intermittent problems with kodi even on the older versions with random lockups. usuallly nothing really shows in the debug logs either.

    finially i found making sure that everything in the library was named in the same manner fixed all the issues and now i have 11 boxes in the house all pulling from the same db on my network storage arrays.

    If i am understand you properly it sounds like your saying that if Android on the box is run then that dvb chipset driver is being found while under LibreElec its not seeing that chipset at all.

    If thats right then my quess is that your kernel probably isn't loading everything it needs to make that dvb chipset work. The dtb part your talking about is only part of the hardware setup. I am not sure what all chipsets are already available to LibreElec thru the various packages so you may need to look in that area.

    Looks to me like the AVAILINK AVL6211LAX is just another chipset kinda like the old B2C2 chipset used by companies like TechniSat and others, meaning basically a bunch of manufactures making real products will leverage against the chipset maker keeping costs down.

    Depending on your coding skills you may be able to glean enough info out of running under Android to create the Linux drivers but from a time investment point its not worth the effort unless your going to support a bunch of boxes and need to support them, better investment would be in a box with a chipset thats acually supported under Linux.

    You may be able to look around tho for other boxes incorporating that chipset and see if any of those makes/brands are included in LibreElec's dvb addon packages. Or if you can find someone using a dvb card in their Linux box that has the same chipset as then you may be able to use that driver and just create a package for it and add it to LibreElec. I use to do that quite a bit with the B2C2 Flexcop chipset as theres a bunch of Manufactures that used that chip.

    Here in North America i found most of these Android boxes with Dvb built in are pretty much useless unless your just trying to pull a feed off what little is left open for fta in this hemisphere. Trying to do any of the North American Sat Providers is pretty much beyond those types of combo boxes as they just don't have the horsepower to keep up with the CA setup ontop of dealing with processing the Dvb downstream.

    wow... i can't believe that git's still kicking around.

    Thats a pretty old project and probably more work then what its worth trying to glean whats needed to try and rewrite a newer driver for the newer kernels

    A lot of the cheap dvb hardware manufacturers tend to swipe firmware from other bigger companies so the available drivers and software tends to be small when it comes to proprietary code. The dvb industry used to be really competitive tho things have gotten better over the years the old thinking still tends to get in the way when it comes to open sources tho.

    not to sound negative but as far as Khadas goes i think they need to worry more about actually producing the sbc's and a little less on all the extra add-ons that seem to be all thats actually available with the newest stuff.

    I have long since gave up trying to source a edge from them as it seems to be one delay after another so i sourced a couple of different RK3399 based sbc's instead.

    i did purchase a couple of vim2's tho to checkout the board to see if it would integrate into a project i am working on and to be honest must say i was not all that impressed with the actual board level quality for the price range of that board. Just to qualify i have a full rework lab here and work with Bga mounts and decap chips all the time and after lifting a 912 off one of the Vim 2 boards would say i have seen better mounting and solder profiles on some cheaper android boxes, maybe it was just this board but i am not sure i want to pull the soc on the other board just to look.

    I will look at the N2 when and if i decide to look at another Amlogic SoC and HK;s been around building boards a lot longer and seems to produce quality boards at a reasonable price. Or i will wait and see what and if Pine decides to offer up in the future as i have already bought a couple Rockpro 64s and found the manufacturing level of those boards pretty pretty decent.

    not sure what to say as i kinda was just vaguely following the post and have not really looked at the way his build is handling the multiboot. Im currently building his build with a added project and will check it at home once the build is done (im building it here at work).

    I wonder if resetting the uenv the way kszaq suggested earlier removed the multiboot patch from the resident u-boot which would mean you need to go back to how you originally installed everything again.

    If you had a serial port i would say start the box up while watching the serial port and hit the enter key immediately as that will freeze u-boot and dump you out into a command line where you can check the uenv variables and see whats going on.

    i just quickly looked at the projects sources and see its a bit different then what i typically see so maybe once i get home and can test this build and see whats what i may be better suited to try and help.

    theres lots of interesting things out there to look at these days but its probably best to start with what your expectations are from the unit and where your interests lie. as well depending on your technical skill set and if you like to play or are strictly looking for a pick and play solution.

    i only add the technical skill set statement as putting most of the bs advertising crap aside one of the main things to consider is support for whatever you buy. if your the type that like to play and try things its probably best to buy something that you typically would see supported on places like here and some of the other forums like CoreElec and others.

    Ive not looked at the actual build's sources in this project but just patching the install to flash script to just rem out the s805 script as part of the install process would work in most cases, then if you ever wanted to reboot from the card just unrem the file.

    sometimes its just easier to restore the default uenv values, unless the autoscript was doing more then just installing the s805/s905 calls then maybe doing a uenv restore wasn't good as it would undue the other things that script was doing as well.

    it kinda comes down to what method is being used by the coder doing the build. in the end i found rather then trying to keep track and up with what all the others were doing to just build a smarter set of scripts that allow the running u-boot to better understand whats going on and work appropriately. some boxes with bigger internal storage i have partiioned up and installed mulitple setups and have more like a grub style loader. Its probably not for everybody but this lets me easily check and compare my builds with a simple reboot and not having to constantly change and re-install systems. I also you tftp to work on u-boot while developing.

    actually i just added a M8S project to Datrh's LE9-Kodi18.2 and am currently compiling to see how well it works as i have probably 50+ M8S boxes sitting here from a dealer here in Can that went tits up after the government charged them (iNL3d), so it would be nice to make them work and get rid of them as they all have 4.4.2 on them which makes them useless but for something like libreelec they would still be fine.

    i agree... in the way back days i used to do a lot of hardrive recovery and even then windows sucks when it comes to low level stuff, i used to have proprietary cards for the pc that the drive would clip into that way windows only contolled the embedded controller on the card that actually did all the recovery stuff... When linus 1st released his kernel and slackware appeared i moved off windows and worked in linux as it very rarely requires any external hardware to do the recovery work. gparted and straight command line fdisk usually work fine.

    in this case i thinks it a matter of not getting beat by the card... lol... sometimes one just wants to know no matter how much time it costs ya... i am the same and hate when something stumps me but your right cards are so cheap these days it really isn't worth ones time anymore.

    just a thought as i see your talking about a Sandisk and i have seen some from them that if your not using fat32 they don't work. not sure what format your using.

    if you have a unix box i would try gparted and if your stuck with just a winblows box do as suggested and use any of the linux distro's Live version and run gparted from there.

    Windows really is crap trying to format anything thats not ntfs or fat32 and even a lot of the so called speciality tools for sd-cards that run under winblows can't do certain things depending on whats wrong with the card, most of those tools still have to go down thru windows to gain control over the port and unless they have a special driver with the software have to rely on windows passing control to the hardware port.

    Linux is a better way when it comes to gaining control over anything hardware wise and if the cards got some weird corrupted block on it theres not much in windows that will touch it. thats why the cheap tools are free... most of the more expensive recovery tools have specialized drivers that force windows to hand over hardware control of the device for low level functions.

    try as DaFlex suggested and use gparted and if that don't fix it pitch the card as your time's probably worth more then the card is.

    These SoCs are designed to look for code at a specific address as they fire up and basically they get it all from U-boot as the system is being brought up. This is somewhat of a oversimplified statement but good enough for this purpose.

    When u-boot starts it reads its stored environment variables which tell it how and what to look for as it starts to run. Typically the standard variables basically just tell it to look in internal storage for the images to load into ram and use. So u-boots environment needs to be changed to tell it to include looking elsewhere then just internal for images to load to ram.

    This is where the autoscripts come in. aml_autoscript is the script that contains the environment changes that need to be fed into the running u-boot to add and store to static memory the variables to tell it to check for either of the files listed below and if so call them.

    Then theres the S805_autoscript or S905_autoscript files that are the routines that actually make the choosen method and go do it. Unfortunately a remnant of some of the current methods are strickly based on whether or not the sd-card is present when the running u-boot pulls the system up.

    So to fix that the level of checking needs to go further then just looking to see if the sd-card is inserted or not at boot time.

    Adding some variables or register checks can be used to make u-boot realize that its actually booting up on internal and from that point forward treat anything plugged in the slot as strictly external storage. How one goes about creating that extra start up intelligence is up to you as theres more then just one way.

    The aml_autoscript is capable of being used for a lot of other things as well but in this case i have confined its use to the subject of multi-boot.

    Because of the way its being used in this case thats why people like balbes refers to only having to install the multiboot once. because typically after the initial use of the aml_autoscript U-boots environment has now been altered and stored in static memory to check elsewhere when booting. Its only after something else rewrites or restores the original u-boot environment that you need to re-apply the multiboot patch, either that or if theres a new multi-boot itself being used.

    hope that helps.

    Its probably not so much as the Nand is bad as it is that somethings flipped a bit or two in one of the control registers that have it locked.

    I have changed flash chips tons of times over the years on bad boxes and found that once i have them off and put them in a programmer i can recovery them and they work fine after that. once and a while the factories will get a bad batch that usually won't properly checksum cause they are flawed at substrate level but that doesn't happen very often.

    Based on some methods of hacking locked boot sector on certain chips things like over voltage and under voltage in a properly timed sequence will release the locking mechanism's that are built into a lot of chips for security reasons and i think based on a accumulated group of issues that sometimes the in-circuit programming being run by the SoC may be replicating those glitches at times under certain circumstances which results in what appears as bad nand when its really just locked. Most newer boxes i don't see that very often on anymore but the older boxes (especially certain factories) were more prone and usually they were a clone of some type. As well the methods of loading linux on these boxes has somewhat changed and gotten better over the years as well.

    That topic seems to be a Annual Statement that keeps re ocuring for the last couple of years. I agree with the sentiment and that companies like Amlogic need to get their heads outta their butt's and help out but there always HAS and always WILL be hackers that like to play and someone will keep things going as long as there is published source code available.

    I get why places like here and others want to see things like compliance and fit be put into place as they have now become businesses for some individuals and no longer just a collection of avid free coders trying to do their own thing without any real care other then making something work. LibreELEC is now a product just like Kodi became awhile ago and with that things change. I have watched as this place 1st broke off OpenElec to go in their own direction and what was once a just make it work on a few boxes agenda has now changed to make it work on as Many devices as it can and for that to work means things need to be in the mainline sources.

    Don't get me wrong tho as i see nothing wrong in any of that as its just the nature of change.

    Kodi is no different as i have watched it change since it began as XBMP all those years ago, and as long as the sources are available others that have nothing to do with the official group will use and alter them to whatever purpose they require.

    but there is always someone that comes along that is willing to keep old things working on newer software even it if's just for their own use which usually ends up out in the public once others become aware of it.

    A year is still a ways off and my guess is that with all of the issues that need to be fixed and then all being stuffed into the mainline streams won't be totally done. Based on conversations with others i know they really could not give a rat's arse about everything being put into mainline as their concerns are strictly based in working code that keeps boxes streaming and if parts of the build are non-mainline or in the form of proprietary blobs that suits them fine.

    Depending on how the bootloader code is setup this probably is a byproduct of some of the current popular methods of creating a multi-boot and because of the way u-boot has been altered to handle this type of multiboot. If the internal u-boot sees the card it thinks it needs to use it to pullup the system and run from there.

    Other methods of creating a multi-boot that use different code in u-boots monitor to set things up different so it can realize to just treat the sd card as external flash can be done as well tho.

    Not sure why so many people have problems with changing ip's and mac's tho as i have never had those issues and at any given time i probably have a least 6 boxes or more running on my network. Personally i always use static IP's and once set they never change as well as the mac's i set. Normally i just set them in a script that runs once the box boots up but i have also slipped streamed them into the box's u-boot as well and they always seem to stick...

    Its as Da Flex said earlier. Not all format/partioning tools can handle bad block recovery or remapping... Technically it lies with in the control code in the memory chip and the hardware it controls as sometimes control flags get set that not all tools have the ability to touch. usually a unix box with fdisk or gparted can fix things, but sometimes its more complicated and there just not worth the time trying to fix.

    I don't use head-end for anything here locally but can say that card works here in NA on Linux but required a bunch of code fixes..

    Someone else in the group tho apparently hacked together windows 7 64bit drivers and has it working but without talking to him i am not sure what all was involved. The drivers from the manufacturer (what little they supply) are not the greatest but ,aybe its just here in NA and they work well elsewhere in the world.