tdm

FYI... for those following this thread: The Linux and Windows tools have been updated and now flash xbl properly. This has been verified with real bricked devices (no shortage of those recently!) I'll try to update the MacOS version within a day or two. I asked the Sailfish developers to please remove the option to flash internal storage partitions. They had no idea so many people were doing this, and said they would fix it soon. That's great, but why didn't they know? Did nobody file a bug report or anything after bricking their device?!?

This is in the splash partition. It's a BMP file with a custom header prepended. I don't know the header format off the top of my head though. Feel free to play with it, it's a rather easy customization. Also please note the "powered by Android" text, including font, size and color, is mandated by Google for play store certification. There is no use requesting that FxTec change it.

You can flash system without affecting data, this is exactly what OTA updates do. But you do need a PC and adb -- you can't store your system image on the data partition. The OEM should fix the speaker swap issue. Has that been noted by FxTec? And for others complaining about backups, you need to do it the way that Google intended ("adb backup" and mtp for media) until a decent TWRP appears. Just an inconvenience, really.

Basically it's a standard Qualcomm device. Meaning that data is encrypted and this cannot be disabled. The method of encryption varies: stock uses FDE while my lineage ROM uses FBE. There is currently no TWRP that can decrypt data but it's on my todo list. If you mean a locked boot loader, yes it comes locked by default, and can be unlocked. However, being a device aimed at hobbyists, FxTec chose to disable Secure Boot. Which basically means that you cannot force your device to only run OEM signed code -- it will always allow you to flash a custom ROM

Sure, it seems silly to me also. But that's the way the keyboard is printed. I would map the fn keys to something else but they are required to generate '/' and '?'. But the beauty of the new keyboard driver is that you can remap all the keys. The gpio keys aren't remappable yet but I'd like to make them remappable before I finish.

I am going to make the default keymap as close to what one would expect by just looking at the keyboard as possible. That means: * The right-slant-arrows (fn-keys) are (dead) modifiers that allow generating the yellow symbols. * The FxTec key could be anything, really. Home would be fine, or any other reasonable suggestion. * Chording the FxTec key (FxTec+number) is sort of asking for two things at once -- you want it to be both a normal key and a modifier key. That's probably not easily doable. But I would like a way to generate F# keycodes. I was thinking maybe fn+ctrl+#

I'll look at audio soon, thanks for the log.

Using mkbootimg can be confusing and frustrating. I use a script to repack boot images after modification: repackbootimg It expects the files created by unpackbootimg to be in the current directory. It also can repack the ramdisk if it is extracted under a directory named initrd. Something like the following will do this: mkdir initrd cd initrd cat ../boot.img-ramdisk.gz | cpio -id cd ..

Unfortunately stock kernel does not have pstore configured. So no can do. 😞

The way I find the easiest is to unpack the boot image, edit it, and repack it. In the ramdisk, you can replace adb_keys with your own host key and/or set ro.adb.secure=0 in prop.default. EDIT: If you are building, you might want to follow this pattern for ensuring ro.adb.secure is 0: https://github.com/LineageOS/android_build/blob/lineage-16.0/core/Makefile#L1476 This is probably much easier than hunting down everywhere that might set or override ro.adb.secure in the build tree. I can also shoot you some patch(es) for adding adb_keys into

Yes, the device boot ROM communicates with a very simple protocol to download firehose, which is an ELF binary. After verification, it simply runs the binary not unlike running a command from a terminal. I'm not sure if the OEM builds the firehose, but they do sign it. An OEM typically has a separate signing key for each device model. Yes the firehose can be used with any tool. And of course access to the firehose can be dangerous. This is one reason the qfp file is not a simple zip file. No I don't have firehose source. But I could look into releasing some

Because FxTec gave us a nice fully functional keyboard (with a couple compromises for size, to be sure) and I think it should act like a full size keyboard.

Okay still, I will let you work out changes to the keymap. But let's investigate the fn key (yellow arrow) issue. Can you send me a kernel log with the following actions? * Press Q. * Release Q. * Press and hold fn. * Press Q. * Release Q. * Release fn. I don't need the entire log, only the part where you are pressing the buttons as above. If I can't figure out what is happening from the log, I may need to add some logging to the GPIO key section (NB: the shift, ctrl, alt, fn, and fxtec keys are driven by separate GPIOs, not by the

The device encryption/signing keys are not kept in flash, they are in a separate non-volatile storage which cannot be read outside of TEE (the walled-off "trusted" environment). So no, it does not defeat locked bootloaders nor does it expose your userdata (because userdata is encrypted with a complicated algorithm that uses both the device encryption key and your passcode). But it does mean that if you aren't encrypting your userdata, it can be trivially exfiltrated. Which is one of the main reasons I won't make a build that uses unencrypted userdata. I have not signed any NDA w

Thank you for the feedback! The cursor key arrow issue and the key lighting issue are both known. I will fix them with the next build. I have no idea about caps lock. If the light turns on, it is definitely sending KEY_CAPSLOCK to the system. Which yellow keys are not working, exactly? I am aware that the yellow fxtec key does not work, but are there others? What do you mean by the ` (backtick) key? There is a key to the left of backspace which is labeled with a ' (apostrophe) and ` (backtick). It should generate KEY_EQUAL normally and shift

If you want adb logging from boot, you need to edit /system/etc/prop.default and change the value of persist.sys.usb.config from "none" to "adb" (or "mtp,adb" works also). No other changes should be necessary.

Yes, Lineage recovery requires your host PC's adb key to be packaged into the boot image because it cannot decrypt /data. If you really want a shell in recovery, I can explain how to do this, or build a new boot image with adb authentication disabled.

The developer option is permission to run adb in root mode. It does not actually restart adb. You must do that separately with "adb root".

That is strange. No you should not need to reset or reflash to make it work. And you are running lineage test 3? With no modifications like magisk?

Actually EDL can both read and write. And that means you can read the GPTs, parse them, and do all sorts of cool things. But most people only want to get their device running again and in the most foolproof way possible. So all EDL tools I've ever seen only have logic to write everything from the factory package. On the other hand, you rarely see factory packages due to security reasons. My tool is unique in that it allows you to only flash the base data. And that it runs on many different OS's, etc.

Hmm, so it looks like you are using Linux and you are rather anxious to get your device working. I can't blame you. 🙂 Please try this test version of the programmer. It is a CLI version, and it has the fix to flash xbl properly: http://files.nwwn.com/android/pro1/qfpkg_cli.gz And a smaller "base" version of the 20191028 package which does not flash system, vendor, userdata, etc.: http://files.nwwn.com/android/pro1/QX1000_user_20191028_base.qfp Please report back and let us know how it goes. 🙂

@Wikiwide do not worry about the age of your laptop or the charge in your phone battery. EDL programming is not very demanding on speed or current, and the device does not use the battery at all in EDL mode -- it does not operate on battery power nor charge the battery. In fact, if you disassemble the device, you will find that you do not even need to have the battery connected to use EDL mode.

@Wikiwide Please read my factory restore page here: http://files.nwwn.com/android/pro1/factory.html This explains the function of the xbl partition, which in turn explains why you are stuck in EDL mode. Note that EDL and QDL are pretty much interchangeable. The device is failing to start and entering a state that allows you to restore it to a functional state. This is marked by the USB device ID 05c6:9008 which is the definitive indication that EDL mode is active. Unfortunately, Sailfish seems to be producing a steady stream of bricks and I'm afraid it won't let up u

That will be fixed in the next build. But yes you can also play with the keymap.

Okay all you qwertz folks, here's a Lineage boot image with my new keyboard driver: files.nwwn.com/android/pro1/boot-newkeyboard.img To use it, flash it to your boot partition, "fastboot flash boot boot-newkeyboard.img". Upon reboot the keyboard will have version 0002 which will make Android ignore the custom keymap file in the vendor partition. You will find the following files: /sys/devices/soc/c17a000.i2c/i2c-6/6-0058/layout This is the layout file. It can contain "qwerty" or "qwertz". So start by setting it to qwertz: echo "qwertz" > /sys/devices/so