Posts by buzzmarshall

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.

Quote from datrh

no kodi 19 for us

Amlogic: Remove Platform by lrusak · Pull Request #16043 · xbmc/xbmc · GitHub

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.

if your at all comfortable opening the box up then the best way to figure it out is to look for board markings and try and identify it that way. there is a lot of clone boxes around so its hard to say for sure.

a sure fire way to know tho is to look on the board for a serial port connection which is probably unpopulated pads but its only 3 wires to hook up a usb/serial uart adapter and get a serial port connection running. If you get the serial connection working you can use any terminal program on windows or mac or linux to freeze the boards boot loader (u-boot) and capture the boards required info to help steer you in the right direction.

normally that stuff comes apart fairly easy if you don't just rip it fast when taking it apart. so you should be ok if your carefull when removing the lid.

ya thats not really the best thought out approach but seems typical of a lot of makers.usually it only breaks and tears if its getting old and been overheated alot.

I usually see that type because you can buy it in various thickness's where they are trying to use the heat sync on more then just the main cpu and it will be applied to help make up for the gap between the other chips and the bottom of the heat sync caused by the main cpu sitting up higher then the other chips once the heat sync is sitting down on the cpu.

eg: i notice on my rockpro64 that the heat sync once on leaves a small gap between the tops of the memory chips and the bottom of the heat sync and if i was worried about heat it would be ontop of the 2 memory chips that i would apply a small pad of the right thickness of that type of material.

i didn't buy any of there cases for my board as it i now have a couple of different sbs and other boards that are slid into a 19" rack mount case with a back plane board on it that i built.

sofar from what i have seen with the rocks i recently bought is that they are actually running pretty cool compared to some of the other things i have seen sofar. last week from wed night to sat night i continually streamed a wide variety of movies in various formats and sizes continually from my san cluster in a cue and found the heat sync (25mm one) never went any higher then 43.6 C . that was just based on streaming movies but seemed pretty reasonable to me on something like that.

without seeing the pad i can only guess. but if the thermal pad itself is blue which is usually what i work with are you sure its not got a clear protector on both sides?

i buy thermal pad in 12"x12" sheets in a couple of different thickness's and the pad itself is blue but it has a clear protector on both sides that get peeled off and it doesn't matter which side goes to the cpu or heat sync.

Lu sorry i should have read your post more closely...

outside of the graphics stack still at least short basically in the userland area such as the drm/abi . I am not sure what else is still a issue for people working on stuff in the public.

privately most of what i needed to make work on the rockpro64 seems to be working but to be honest i have been so far running off sd based setup and not looked much at the eMMC or PCIe stuff yet.

I should have also said am working in the the 4.20 and 5 kernel areas...

i would think that publicly they should be in the same general realm tho.

my quess would be to look around Datrh's github which is datrh · GitHub