remay / tmf-hudl Goto Github PK

It would be good to have a documented (and easy?) backup mechanism for people to allow then to go back if they have problems with flashing.

Possibly based on rkdumper? https://forum.xda-developers.com/general/rooting-roms/tool-rkdumper-utility-backup-firmware-t2915363

Perhaps package up a script based on rkDumper and imgerpackrk that can create an image that could be flashed back?

Add option to set the output file name in mkthumbdrive.sh, and modify build.sh to use it.

Haven't found another place to provide feedback, so filing this issue to report that TMF 1.0 installation from SD card works like a charm on a Hudl 1. The documentation is really great, thanks! 👍

There is one Tesco branding 'Cling' left. It is an overlay (cling) as part of the launcher app that point the user, on first boot only, at the Tecso [T] button.

It should be removable by editing the Launcher2.apk file, but it may be that the easiest ting is to try to find a compatible 'clean' version of the launcher app.

Hey, thank you very much for creating this, it's so much better than the stock ROM!

I'm having an issue where the Google Play store won't update (automatically or manually). It's on build 4.6.17 and when I press it to update it simply says "Google Play store is up to date". Not sure what's up with it as at time of writing latest play store is version 33!

Cheers

The stock version (Google+) no longer works and the upgrade (Google Currents) doesn't run on such an old Android version. Either remove the app, or update it to a version of Google Currents that does work (e.g. the version from the Helios ROM)

It strikes me that build.sh might be better implemented as a Makefile, allowing better dependency management?

NOW FIXED - see below and check your USB cable!

Hello, I was really excited when I discovered your Github pages as my Hudl has been unused for ages and my elderly father wanted to try an ebook reader so I thought this would be ideal.

Anyway, I had prevously rooted the Hudl and had a different bootloader (CWM I think) so I couldn't get the SD image to work so I booted a laptop with your bootable USB. All appeared to go ok for a bit and then it stalled. I wiggled the USB cable and things moved along a bit more and kept stalling. After about 3 hours it appeared to complete but, when the instructions said the Hudl would reboot, nothing happened. It looks like something went horribly wrong due to a faulty cable. I have changed the cable and can now repeat the process with a new cable in about 4 minutes but still nothing appears on the screen of the Hudl.

When I connect the Hudl with the new USB lead to my Ubuntu laptop and issue lsusb, this is what I see:
Bus 002 Device 003: ID 2207:310b Fuzhou Rockchip Electronics Company RK3188 in Mask ROM mode

Just wondered if you've come across this before and have any bright ideas? It would be good to be able to use it if possible but it is pretty old so no problem if not.

(I've tried starting the Hudl with Vol+ and the power button, Vol- & power, a pin in the reset hole, holding the buttons for ages, etc and nothing seems to work)

Thanks for all your work.
Alastair

It would be good to provide updates to the stock apps, but when I try to do this as part of the image I end up with an unstable system (and a non-functioning Google Play Services). Currently the stock version of the play store and play services get updated, and then the rest of the apps can be updated, but it would be nice not to have to do this.

Could we re-partition the flash and return unused system partition to userdata? Is this even desirable?

Hello there!

the rockchip flash method didn't work for me as it said something about "download IDB fail", i did not have a SD card to hand so i made a USB stick using the image provided,

i first tried flashing using a Toshiba Satellite C660-2EL and a White USB cable, however when it got to the reboot state the device appeared totally hard bricked, until i removed the battery and restarted again , this time using a Toshiba Satellite Pro A300-22c the flash and reboot worked this time, with it formatting the partitions and it finally rebooting twice, however on the second reboot its just stuck on the "Powered By android Logo" i left it overnight and woke up to a dead battery, is there something else I should try

?

This thread claims to have some overclocked Kernels https://forum.freaktab.com/forum/tablet-support-android/other-oem-tablets/519127-hudl-kernel

Is it worth investigating?

All the environment/build info is currently here: https://github.com/remay/tmf-hudl/wiki/Tools-and-Environment-for-building-TMF-Custom-ROM

We should maintain a copy of this (or perhaps instead of this) in the main repo so that instructions for using the
repo are cloned with it.

As far as I can tell backup.img and kernel.img are not needed. recover-script probably isn't either. It may also be possible to shrink system.img to the size of its content (50% of it's current size).

There are tangible benefits from smaller files - download speeds increase, cp times reduce and the flash times will be smaller - both due to checking CRC/MD5 signatures and due to flashing smaller images.

Flashing from SD card the recovery program definitely expands system.img out to fill the partition (and this could be done in upgrade-script if it didn't. We need to check we don't break RK Batch Tool, and may need to add to init.rc to expand the system.img (if this is needed)

Currently patch-rkimg.pl reads the data from the .img file up yo 4 times. Once each to validate the MD5 and CRC signatures and then another 2 times to create the new CRC and MD5 signatures if anything is changed.

We shoudl be able to get this down to 2 read (one for checking and one for writing) and if we removed the check we'd get it to one.

hey, i have extracted and renamed the image file on my sd card but the hudl doesnt seem to find it. is there any thing o am missing?

DO we want a ROOTed version of the image? If we can work out how to apply updates using update.zip files on an SD card then maybe we can publish a root add-on?

Currently build.sh needs root permission so that it can mount/umount and can correctly manipulate the images.

However this leaves a load of files in .tmf-rom-build/ directory un-editable/un-removable by the current user. This shoudl be fixed.

We should also look to see if we can down-privilege the commands that don't need it to help avoid probelms.

Hello,

Thanks for the workaround to remove most of the Tesco bloat with the TMF Custom ROM Release V1.0.

I have successfully updated the firmware but I fail when trying to add a current, valid, gmail account or create a new one.

Can you offer an further advice please?

Other utilities (notably rooting packages) wipe install-recovery.sh and replace it with their own code ... so, as we're already flashing the whole image it would be better to move our code to its own file and run it from init.rc (meaning an updated boot.img ramdisk)

At least on the thumbdrive flash image we should log what happens to a file on the flash drive so we can get useful information back on what went wrong. Might be easier on the thumb image to modify .profile to redirect (./hudl-flash.sh some.img 2>&1 | tee log.file)

Possibly controlled with a syslinux boot option to avoid unexpected writing to the flash drive?

Should filter the ANSI colour codes to make it readable.

From #23

@JavacHolt sees a failure when trying to flash from SD Card

My initial analysis is

• there's no update to do to the parameter partition
• Update appears to succeed to the boot partition, but this is likely to be due to there being no difference in the boot partition content.
• Update to system partition fails.

If I had to guess I'd say this is another occurrence of a device with read-only EMMC chip, but user says that he can boot the device which wouldn't happen if whole chip is read only. Perhaps it's possible for certain partition to become read-only?

Would we like any additional apps in the stock image? It would certainly be useful to collate versions of apps that still work on 4.2.2 (and are no longer available in the app store). If we can get updates through update.zip on SD card working the publishing app add-ons would be possible.

It seems to be non-obvious that the instructions need expanding.

See #23

Particularly this comment:

OMG!

I am such an idiot - there are hidden instructions... if you know the magic to find them.. lolz.

TL,DR: Reboot step seems to work on Intel processors but not AMD.

Firstly, thanks @remay for reviving the Hudl! I did eventually get this working by using a different computer.

I initially tried this process on one computer, and all seemed to go well until the reboot step of the script where the Hudl seemed to be bricked. I retried a few times on this device with no luck. I decided to try with another computer, and the process worked perfectly! Now I was curious as to why the process had initially failed.

I tried re-flashing on a few different computers I have lying around the house, and I have found that I can only get the reboot step to work when using devices with an Intel processor (other devices were AMD). This could be a coincidence based on other hardware of the machines I had available, but I thought it might be worth pointing out in case anyone else experiences similar issues.

I might look into this further if I find some time.

When trying to flash from a computer it is important to have a good USB cable - many failures are down to the cable (or the Hudl USB connector). Add a warning to the flashing instruction pages to call this out. See #31 as an example of an issue resolved by finding a good cable.

It's pretty dangerous to leave /data unformatted, as we have no idea what may be on it.

Perhaps we can implement most of the changes to /system from an update.zip file on SD card. Needs further investigation.

An alternative strategy may be to just replace recovery partition with a recovery image that has a back up/restore capability and use that to back up before flashing and restore after flashing?

Would finding a CWM or TWRP recovery be useful? Certainly some better backup capability would be extremely useful.

Many of the apps in the Play Store require a version of Android more recent than the v4.2.2 used by the Hudl. We should document how to search some of the APK archives and find a version that will work, and then document how to install an APK from SD Card.

Creating the new bottanimation is painfully slow. Either remove the zopfli compression (do we really same very much?) or cache the output in .tmf-rom-build/cache/ so that we only build it once.

If the Huddle has USB debugging enabled and the host has adb installed then hudl-flash.sh should use adb reboot bootloader to put the attached Hudl into the state ready to flash.

It would be relatively easy to extend this script to unpack and pack the whole RKFW/RKAF file. This would remove our dependence on imgrepackrk and remove additional reads of the entire data for MD5/CRC purposes.

It might even be possible to attach a loop device directly to the system part of the file and do our modifications in-place is we can generate the offsets.

The script should get an option to copy it's input and name the modified output file