I am attempting to repair a bricked Asus X53SV notebook (Asus K53SV board) by reflashing with flashrom from a Raspberry Pi. I've got it all hooked up and flashrom recognizes and reads the chip. However, I cannot determine what type of file the BIOS update is that I downloaded from Asus support site. The update I'm using is K53SVAS.315 for Aptio's Easy Flash. How can I extract the raw BIOS from this file?
After further research, I've determined that the download offered by Asus is not a complete BIOS image file. It cannot be used to reflash the EEPROM directly as it does not contain all of the information required. The built in Easy Flash utility uses this file to update only a portion of the EEPROM. The only officially supported method of repairing a bricked Asus notebook is to send it back to Asus.
I just managed to fix my bricked Asus K53E using instructions from here, yours should be similar. It requires you to download the first part of the flash from the chip and hope that this part is not corrupted.
You have to first dump the bricked flash, then reconstruct the full image by merging it with update file from Asus website using a hex editor as follows:
Reconstructed_Image 0x0 - 0x17FFFF = Bricked_Image 0x0 - 0x17FFFF
Reconstructed_Image 0x180000 - 0x3FFFFF = Update_Image 0x0 - 0x27FFFF
Related
I have an issue with spiffs and arduino.
I'm using ESP07 with 1mbyte of spi flash memory. I'm using arduino IDE.
I have 16 files in my file system being sketched with the option "tools -> ESP8266 Sketch data upload". If i selected 256kbytes as SPIFFS size all works fine. All files are there and the system works fine.
But if I use 512 kbytes for SPIFFS only 8 files are there after using the same "tools -> ESP8266 Sketch data upload" option.
I have verified my flash spi memory with the demo included in arduino IDE "CheckFlashConfig", it is 1mbyte.
I need to use the 512 kbytes model because the customer can upload a file that can be too big for 256kb spiffs model.
As curious stuff, I selected 2 mbytes (even when memory is 1mbyte), asigning 1.5mb/512kbspiffs and it worked fine (probably because the last bit address was ignored and it worked over 1mbyte really doing it 512/512).
I have the option to upload all those files manually and it will probably work but it is slower than just burn the memory in production.
Is it a SPIFFS bug? a problem with spiffs in arduino o maybe something that i'm missing?
Thanks.
NOTE: I'm using esp8266 community version 2.5.0 package
Since I am not allowed to comment:
Please upgrade to ESP8266 v2.6.3:
The SPIFFS as standard file system has been replaced by LittleFS (means small changes in code if using the DIR opject), but offers improvements in regard to reliability.
For testing choose Generic ESP8266 with this params 1MB (FS:512KB OTA:~246KB)
If the problem (unlikely) persists or you dont nred OTA check the partition schemes in
the following boards.txt
C:\Users\YOURUSERNAME\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\X.X.X\
dependingon theversion can be 2.5.0 or 2.6.3
- you can define your custom scheme if you like
For a research project about printing nanofluids with an Piezo electric printer I want to see the the code that the computer sends to the printer. I am running Ubuntu 16.04 and have an Epson Stylus SX600FW printer.
Using Ghostscript 9.18 I want to print a simple ps file and obtain the output file that is being send to the printer. This file should contain some ESC/P sequences if I am right. Now I have some problems with the rigth driver is Ghostscript.
I want to print the file using : gs -sDEVICE=epson -sOutputFile=%pipe%lpr test.ps. The printer starts the print gibberish. Just some letters and symbols on page, not the two words that are in my test.ps.
So probably ghostscript doesn't use the rigth driver. How can I get gs to use the escp2-of-sx600fw or Epson-Stylus_Office_SX600FW driver, as stated on the gutenprint site?
Kind Regards Rick
If you want to use a non-standard device, then you will have to rebuild Ghostscript and tell it to include the device's source in the build.
Nobody has supplied us with source to an Epson SX600FW device, so we don't supply it, not even in the contrib directory. There is a 'vector' Espon device in there, but its not built in as standard.
Looks like Gutenprint itself drives the printer. Presumably it only uses Ghostscript to render PostScript and PDF files into some intermediate format that it can then convert onwards to the specified device format. If I'm right, then you can't make Ghostscript use the Gutenprint device driver, as that will be specific to GutenPrint. You'll have to use Gutenprint to do that.
Context:
I am writing a program, which uses pcap to capture packets in the monitor mode on the openwrt router with ar9331 chip.
I tested the program on a desktop with pcap 1.1 (which existed in my openwrt version) and found an issue: pcap_can_set_rfmon returned true, pcap_set_rfmon returned success, but attempt to activate capture resulted in “monitor mode isn't supported” error.
Google search showed a bug report of similar issue with wireshark. One of the comments says that with some wi-fi devices the issue is caused by an old version of pcap, which uses old version of another lib.
I updated pcap version to 1.5.3 and the issue was resolved.
Problem:
The issue appears again when I port our program to Openwrt. But now update of libpcap package to version 1.5.3 from newer openwrt branch doesn't help.
Sadly, the libpcap monitor-mode code on Linux works best when libpcap is linked with libnl, and it's often not linked with libnl for various reasons (including problems with a program using libpcap and libnl, and linked with a different version of libnl than the one with which libpcap is linked).
This needs to be redone in libpcap. It may end up being done with a "helper process" that libpcap runs to do various things; that would also improve cleanup if the program using libpcap exits abnormally and would allow packet capture operations requiring special privileges to be confined to the helper process rather than requiring the program using libpcap to run with those privileges. This is on my rather long to-do list.
The best workaround is probably to use airmon-ng to turn monitor mode on, as described in the Wireshark Wiki page on Wi-Fi capturing.
I am running into hardware issues that perhaps someone here knows a workaround. I am using a PC and windows.
For several years I have been making interactive installations using video tracking: the Jmyron library in Processing, which has functioned marvelously for me. I use this set up: cctv type microcameras to a multiplexer, the I digitize this signal via a firewire cable to a pci card. Then Processing reads these quads (sometimes more) as a single window, and it has always worked (from windows xp all the way to 7). Then comes windows 8: Processing seems to prefer the built-in webcam to the firewire bus. On previous version of windows, the firewire bus would naturally override the webcam, provided I had first opened a video capture in Windows Maker, and then shut it down before running the Processing sketch. In Windows 7, which had no native video capture software, I used this great open source video editor called Capture Flux. The webcam never interfered. With Windows 8, no matter what I try, Processing defaults to the webcam, which for my purposes is useless. I have an exhibition coming up real soon, and there is no way I am going to have the time to rewrite all that code for Open CV or other newer libraries.
I am curious if anyone has had similar problems, found a work around? Is there a way of disabling the webcam in Windows 8 (temporarily of course, because I need it to be operational for other applications), or some other solution?
Thank you!
Try this:
type "windows icon+x" choose device manager (or use run/command line: "mmc devmgmt.msc")
look for imaganing devices, find your integrated webcamera
right click on it and choose disable - now processing should skip the device.
Repeat the steps to reenable the device.
Other solution would be using commands in processing:
println (Capture.list()); (google it on processing.org) this way you will get all avaliable devices and you can choose the particular one based on its name.
Hope this helps.
I am about to forensics investigation of a linux physical memory. I have dumped an ARM Linux which the profile is not listed in Volatility, so I could find the process and the latest command using Hex Editor. here is the Question, how can I create Volatility profile, should I first find the offsets of the network connection, open ports , sockets..... then go for Volatility ? by the Hex Editor I could see some information in Memory Dump, is there anyone who can help me how can I find the rest. and is it necessary to find all the offsets and address space of each information before creating the Volatility profile?
For network related investigation, do file carving for pcap file. Using tshark to extract remnants from pcap file