I am trying to build v1.2 of firefox os for my zte-open. With a few hiccups I was a able to configure and build it using the inari device profile. But the process fails at the last stage of flashing.
here is the output of the ./flash.sh command
rog% sudo ./flash.sh
[sudo] password for abhiram:
< waiting for device >
erasing 'cache'...
OKAY [ 0.531s]
finished. total time: 0.531s
erasing 'userdata'...
OKAY [ 1.399s]
finished. total time: 1.399s
sending 'userdata' (53571 KB)...
OKAY [ 4.518s]
writing 'userdata'...
FAILED (status read failed (No such device))
finished. total time: 9.911s
After that the device starts fresh with no userdata (obviously). Right now I am guessing that if it passes the user-data phase it might flash the system and boot partitions.
Btw, my phone running the version 1.1 of the firmware, which was from an official Zte update.
update
I tried flashing separate partitions of (system and boot) but the it gives me the same error.
with ./flash.sh system
FAILED (status read failed (No such device))
I have this same problem. However I do not think that fastboot is disabled.. I say that because I can see ROAMER2 if I do a
fastboot devices
Please note.. if you cannot preform that command try running the following command first
adb reboot bootloader
after this I bet you will be able to see the devices using the fastboot command.
So fastboot seems to be able to connect to the device and the fastboot command erasing cache seemed to have worked, and the fastboot command erasing userdata command worked. So my guess is that it is not fastboot itself but the device preventing the push from occurring.
Perhaps there is a log we can read somewhere?
Update:
I called the company. Their official line is that they do not support updating the phone and you should only use the Update feature on the phone itself. There is an update coming however it is being pushed out one a time not a global push to all devices. In some blogs on this subject I saw users complain that the device is advertised as open but is not in fact open. Point being this: If the device is preventing the push as I suspect (then we as a consumer have been tricked) and the device is operating correctly.
Update: (more info)
There is a set of problems and it depends on if you upgraded your phone or not. If you read the discussion here I think it pretty much covers everything: http://www.reddit.com/r/FireFoxOS/comments/1ugx5g/firefoxos_buils_for_zte_open/
Also check to see if your device is rooted by the following
adb shell
if you see $ continue to the next command, if you see # you have root
su
If you are in the same boat as me, and have updated to 1.1 using the ZTE images. Then you are a little stuck. We need to downgrade back to 1.0 revision 2 (B02). This will require the clockwork mod recovery to do this. The problem is that we also need the original img. ZTE has taken this image down. If you have this image or if you can find it please upload it and post it here and in the link I provided (you'll be a hero to a very small group of nerds). Otherwise.. a Mozilla developer stated that ZTE will have yet another update coming soon. (However chances are this is going to be yet another locked down version). So the hunt in on for the original image.
After emailing the b2g-dev mailing list, I figured out that this was a problem with the firmware of the zte-open.
AFAIK, the latest firmware update to 1.1 brings all the devices to OPEN_US_DEV_FFOS_V1.10B01 firmware, which for some reason comes with fast-boot disabled. Hence it is not possible to flash it.
It looks like zte are working to bring out a new update that comes with fastboot enabled. So I guess I'll have to just wait it out.
Update
It took me a while to figure out how to update the damn phone, to upgrade you need to downgrade to the firmware 1.0B02 on which fastboot seems to work.
To downgrade I had to install clockworkmod as the default recovery program complains of signature mismatch( Zte! can't I donwngrade to your older official firmware?).
Rooting and installing clockworkmod, I had to remove some assert checks on the device-name from the updater-script and then pack it. Once this is done downgrading the device is quite simple.
After this I had to individually flash the three images (boot,system,userdata) using fastboot flash command
Related
every since I updated macOS to macOS 12, I have trouble using CoreBluetooth.
In one of my apps, I will list all BLE devices using the CGCentralManager class.
This has worked for years. But now, when I start my app, the following output appears in Xcode:
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
[CoreBluetooth] No name or address
The macOS Console app has many messages like this (I don't know if this is related, the process is bluetoothd instead of my app):
Destroying pairing agent for session <appname>
Erasing session 0x7f795824af00 from SessionMap for "appname-2890-84"
Received 'stop scan' request from session "com.apple.bluetoothd-central-143-2" updateScanParams:YES shouldUpdateState:YES
Stopping scan as there are no remaining scan agents permitted to scan
If my app is not running, the bluetoothd process seems to be rather quiet. Once started, the bluetoothd process seems to have some kind of problem. The question is: which one?
Disabling the Sandbox did not change anything, so I don't think that it has something to do with missing permissions.
I also built a very basic example in a new app. I instantiated a new CBCentralManager and started scanning. The devices were discovered.
I my main app, no delegate function is triggered. None at all.
Did anyone encounter the same issue?
UPDATE: It appears that Apple has fixed the bug in macOS 12.3.
Original answer below applies to 12.0, 12.1 and 12.2.
It appears that Apple has updated macOS to behave more like iOS. The docs for scanForPeripheralsWithServices:options: say:
Your app can scan for Bluetooth devices in the background by specifying the bluetooth-central background mode. To do this, your app must explicitly scan for one or more services by specifying them in the serviceUUIDs parameter. The CBCentralManager scan option has no effect while scanning in the background.
Command line programs cannot ever be considered the foreground app since they are not a .app and therefore the background scanning rules apply. (This is conjecture, but I suspect that NSWorkspace.frontmostApplication might be used to determine the "foreground" application).
If background scanning is acceptable and the Bluetooth devices in use include a service UUID in the advertising data, then a list of service UUIDs can be supplied to scanForPeripheralsWithServices:options:.
If not, then you have to create a signed .app to use foreground scanning.
Some additional details and an ugly workaround for running a command line tool without a GUI as a .app (outside of the XCode debugger) can be found at https://github.com/hbldh/bleak/issues/720. This link is Python-specific but one should be able to extrapolate it to other environments.
I am running Linux kernel 4.14.149 built by Yocto Zeus, and I am running 2019.07 U-boot. At the recommendation of our security team, I am trying to get rid of the Linux console. I am not worried about debugging (once I get this to work anyways); we have other ways of getting the system logs out of the machine, and this will not be done on software development boards. That mechanism is already in place and is tested working. We have an i.MX6 as our core (this is an embedded system), and we have dedicated UART5 to our console on dev boards.
I have tried a few different methods to do this. The first was to disable the framebuffer console kernel config (CONFIG_FRAMEBUFFER_CONSOLE). The primary issue with this approach is that it disabled the splash screen. We have a splash screen that is put up in U-boot (and it is displayed again by Linux), but Linux appears to reset the framebuffer or something when it is booting, resulting in the display flickering and being blank for a bit before our applications start, which was unacceptable (and is the reason we put the splash screen up in both U-boot and Linux).
I also tried just setting "console=" on our command line. This is close to what we want to achieve in that the console doesn't come out the UART anymore, but we see it start to appear on the display on top of the splash screen. I haven't found any way to fix that (I can upload a screenshot if desired).
Just eliminating the console parameter entirely didn't appear to work, it still came out the UART. This is to be expected based on the serial console documentation which says it just uses the first available device.
I have tried commenting out the console initialization in main.c in the Linux source, which exploded rather quickly.
I tried setting to be a netconsole (see Where do you send the kernel console on an embedded system?) but the splash screen still got overwritten, same as the setting it nothing case.
The last thing I have tried was just setting it to a bogus device ("console=ttymxc9" on the Linux command line). While this appears to work (there is no data on the display or the UART) it appears to stall (crash?) partway through bootup and without being able to get the logs (it stalls before our application service runs). I say stall because we have Linux configured for a heartbeat and we do still get proper LED heartbeat behavior. None of the systemd services I added to our build however appear to run (I added one to save the journalctl log file after boot to a file on an external SD card for debugging purposes until I get this working)
At this point, I have run out of ideas on how to get rid of the console while keeping the splash screen intact. What is the proper way to disable the Linux console?
For kernel versions 5.11 and newer:
In the submenu "Character devices" under "Device Drivers" from make menuconfig, there is an option called "Null TTY driver" (CONFIG_NULL_TTY) that you can enable and add console=ttynull to the kernel boot cmdline so that all console output will be simply discarded.
You can also disable CONFIG_VT and CONFIG_UNIX98_PTYS, since you don't need to interact with your program via console at all.
For older kernels (like my 4.14):
You can add this support with the diffs at: https://lore.kernel.org/lkml/20190403131213.GA4246#kroah.com/T/ and then follow the instructions above.
More recent versions of yocto use systemd and a service called getty.target to load the serial port console. Disable by running the following command (once):
systemctl mask getty.target
This answer may not fully fit your question, however, it could serve as a research source for other users, just like me. I use the commands below to temporarily turn the console (ttyS0) on and off.
systemctl stop serial-getty#ttyS0.service
and
systemctl start serial-getty#ttyS0.service
I am attempting to install Cubase Elements 10.5 'stay at home trial but fail to get any audio.
I have followed numerous guides online about shuffling various Gb files around (surely thats the installer job) but still nothing.
All audio mapping shows as connected.
When testing eg using the Production > Blues Rock Production (so its not even setup), for each Channel I get the error message:
The current preset or project was created with a previous version of HALion Sonic SE. If you modify the preset using new features of this trial version a previous version might not be able to load it or the preset might sound different
if I just click ok and load the project it seems to play, but no audio or output levels show.
I am getting nowhere with Steinburg 'Support', raised a support request and this is just ignored.
I have been trying to get this working for about a month and installed several times.
VST Connections
Audio Device and Driver
The application is in focus when it fails to provide audio, not sure where to make it play in background.
Screenshots of fault:
Chose a project as test, but when loading each of the channels shows this error,
I click ok to make it load:
Press play, no sound
but see it playing here:
Attach a screenshot of your VST connections in Cubase to help others diagnose your system.
Ensure you have latest drivers for your audio card etc.
Ensure your operating system (or any other background/foreground app) is not using the outputs you have selected in Cubase.
as they may not be multi-client.
ASIO compatible hardware is recommended.
Ensure background audio is enabled in Cubase if the application is not in focus.
Confirm that you have followed at least the steps above in any further replies. Specify your level of experience with computer audio in general, so that further information is relevant to you :-)
What I am looking for: I need help debugging consistently happening system crashes on my Jetson TK1.
System: I am using a Jetson TK1 board from NVIDIA. Updated to 21.3.4 Grinch Kernel. All drivers installed, libopencv4tegra installed alongside ROS (using hacked deb packages to not overwrite openCV). Everything used to work perfectly in this exact setup.
When the crashes happen: I am running a VSLAM program, which uses a camera connected on the USB port. The program is making heavy use of OpenCV. The program used to run for over 1 month without problems in the current setup. Now, I am getting consistent system crashes which result in a total system freeze. When I am connected over ssh, I loose connection. When I connect a monitor to see what happens on the system while it crashes, I can see everything freeze. The USB port also seems to turn off, since not even USB mouse and keyboard work anymore post-crash. The Jetson stays on though.
Crash Logs: I have tried looking into the /var/log/ logs, but none of them show any messages for when the crash happens.
I have run memtester before. It didn't return any bad memory. While running and crashing, the memory onboard is used at about 60-75% (as shown by "top"). CPU usage is around 60%.
The weird thing is that this exact setup has been running just like this for over a month now.
I need to know: are there any other logs I could find information about the crash in? How could I find out if this is related to a hardware failure or whether there's a software issue?
Thanks
-Marc
I'm having some problems with fingerprint reader on Thinkpad T430 ID 147e:2020 Upek
For few days i was trying every tip i could find but it didn't work for me.
Mainly i tried to Build and make it running through Fingerprint GUI and i was able to build it and install it properly (after few fixes) but it simply was not able to pick up my device.
At one point i thought that i have solution, since i realized that Fingerprint sensor on this laptop is quite new and is maybe not supported by default with proprietary libbsapi.so so i tried to follow tips from this blog: http://volker.de/2012/12/fingerprint-gui-und-das-thinkpad-t430s/
Guy has exactly same device and in same PC but as i expected it didn't work for me.
Platform is Debian-squeeze
If you have any idea what could be solution, pls help.
Used the same info as you did, but a quick look at the French Ubuntu doc did the fix for me: the problem appears to be that the fingerprint-gui doesn't have access to the USB device bus, thus, we have to give it to it.
Find your device's bus and device adress using the lsusb command, for me, it was:
Bus 001 Device 003: ID 147e:2020 Upek
Thus the bus is 001 and the device is 003. Let's call them x and y.
Then, we use chmod (apparently it doesn't pose any security threat as the system fixes it by itself):
sudo chmod 666 /dev/bus/usb/00x/00y
For me, for instance, it was:
sudo chmod 666 /dev/bus/usb/001/003
Then, follow the instructions given to you by the German guy (volker - the link you cited).
On my side, I was running Ubuntu 12.04 (debian bro'), so I could use the fingerprint PPA. I don't know if Ubuntu PPA's work on debian. I suggest you keep your own install of the fingerprint-gui program, as well as the fix provided by volker's blog post. Then, just launch fingerprint-gui and it should recognize you device.
The German blog got actually updated was a problem with the quotes:
For non german users:
Be aware to use the copy and paste funktion to insert the above lines in your 40-libbsapi.rules, because the quotes are different from that quotes that you get when hitting on your keyboard.
It was pain in the a….. to find it out.
You'll need to apply this patch to libfprint.