I have a gateway device with MT7620a in MIPS architecture. The device has installed OpenWRT. If I connect to device via UART with the goal of flashing new firmware I see something I don't understand, MCU loading two version U-Boot.
U-Boot 1.1.3
Ralink UBoot Version: 4.3.0.0
Here is Log System after start
U-Boot 1.1.3 (Apr 27 2015 - 13:54:38)
Board: Ralink APSoC DRAM: 128 MB
relocate_code Pointer at: 87fb8000
enable ephy clock...done. rf reg 29 = 5
SSC disabled.
spi_wait_nsec: 29
spi device id: 1c 70 18 1c 70 (70181c70)
find flash: EN25QH128A
raspi_read: from:30000 len:1000
*** Warning - bad CRC, using default environment
============================================
Ralink UBoot Version: 4.3.0.0
--------------------------------------------
ASIC 7620_MP (Port5<->None)
DRAM component: 1024 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 128 MBytes
Flash component: SPI Flash
Date:Apr 27 2015 Time:13:54:38
Of course I have a few additional questions in this issue:
What is different between these U-Boot ?
Why does my device need two versions U-Boot ?
Whether this u-boots need separate *.bin image or these is together
in one image *.bin ? In my device is only one partition for u-boot image and one partition for variables:
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
As Alexandre Belloni said, there is probably only one version of U-Boot on your device, it just has two different version identifiers.
The reason for this is that manufacturers often need to modify the U-Boot source code in order to get it to operate on their device, or to add features.
On your device, it looks like the version of U-Boot that Ralink pulled from the official U-Boot source code repository is 1.1.3. Ralink's own internal version number that they use for tracking their internal modifications is 4.3.0.0.
There is probably only one u-boot and "Ralink UBoot Version: 4.3.0.0" is an internal u-boot version for Ralink.
Related
Octave 4.0.0 works on Windows 7 32 bit. I have just downloaded 4.4.1 and it has never worked.
Following information:
Problem signature:
Problem Event Name: APPCRASH
Application Name: octave-gui.exe
Application Version: 0.0.0.0
Application Timestamp: 00000000
Fault Module Name: Qt5Core.dll
Fault Module Version: 5.11.0.0
Fault Module Timestamp: 00000000
Exception Code: 40000015
Exception Offset: 002e8696
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3081
Additional Information 1: d1e0
Additional Information 2: d1e00fdc0b78c108f75564157f84c2f0
Additional Information 3: f785
Additional Information 4: f7855e1e76ad3f0614cfa9b98110597e
Found a vaguely similar problem, failing to start GUI on Windows 10, applied suggested solution of setting "Disable display scaling on high DPI settings" under Compatibility tab of executable Properties.
If you download GNU octave from octave.org you'll see a list:
Windows-64 (recommended)
octave-4.4.1-w64-installer.exe (~ 238 MB) [signature]
octave-4.4.1-w64.7z (~ 267 MB) [signature]
octave-4.4.1-w64.zip (~ 481 MB) [signature]
Windows-32 (old computers)
octave-4.4.1-w32-installer.exe (~ 238 MB) [signature]
octave-4.4.1-w32.7z (~ 267 MB) [signature]
octave-4.4.1-w32.zip (~ 481 MB) [signature]
Of couse a 64bit built will NOT run on a Windoze7 32bit so you have to get octave-4.4.1-w32-installer.exe and install this
I have followed instructions here and successfully build and setup geth.
Ethminer seems to work except it doesn't use the Titan X GPU and the mining rate is only 341022 H/s.
Also when I try to use the -G option ethminer says it is an invalid argument; the -G flag also doesn't appear in the ethminer help command.
Your GPU must have a minimum memory to perform mining. Upgrade to GPU you with higher memories (minimum 4GB is preferable)
The current DAG size is above (2GB). That means you cant mine with GPU with memory less than 2GB.
I'm little bit new with tensor-flow.. so please be gentle with me..
I have problem with creating second process that load tensorflow on already working GPU.
the error I get is:
\cuda\cuda_dnn.cc:385] could not create cudnn handle: CUDNN_STATUS_NOT_INITIALIZED
\cuda\cuda_dnn.cc:392] error retrieving driver version: Permission denied: could not open driver version path for reading: /proc/driver/nvidia/version
\cuda\cuda_dnn.cc:352] could not destroy cudnn handle: CUDNN_STATUS_BAD_PARAM
\kernels\conv_ops.cc:532] Check failed: stream->parent()->GetConvolveAlgorithms(&algorithms)
\cuda\cuda_dnn.cc:385] could not create cudnn handle: CUDNN_STATUS_NOT_INITIALIZED
Hardware details :
super micro - 4028GR-TRT
8 GPU's 1080
CUDA: 8
cudnn: 5.1
windows: 10
tensorflow: 0.12.1 / 1.0.1
My PC shouldn't be a problem
windows 7
gpu 1070
cuda 8
cudnn 5.1
tensorflow 0.12.1
Can someone tell me why on my PC everything is ok but not on the big one(supermicro)?
is this windows / driver issues maybe?
I try to update NVIDIA driver.. no help on that ..
TensorFlow is not always good at sharing GPUs with other processes (including other instances of itself!). The typical workaround is to use the %CUDA_VISIBLE_DEVICES% environment variable to prevent the two processes from clashing over the same GPU. For example:
C:\>set CUDA_VISIBLE_DEVICES=0
C:\>python tensorflow_program_1.py
While in another command prompt you could tell TensorFlow to use a different GPU as follows:
C:\>set CUDA_VISIBLE_DEVICES=1
C:\>python tensorflow_program_2.py
My graphics card
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3410/3430] (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device 30e9
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at 80000000 (32-bit, prefetchable) [size=256M]
I/O ports at 7000 [size=256]
Memory at 98400000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 98420000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: radeon
So i do not have NVIDIA card,does this mean I can not install it?
No, it does not. You can install it with CPU_ONLY=ON variable in cmake. Of course, CUDA will be unavailable for you, but you still can use caffe on CPU.
Moreover, you can try to checkout opencl caffe branch to utilize your AMD hardware (but I didn't try it yet).
I am using Fedora and when I execute $ hackrf_info in the terminal, this is displayed:
Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1
Part ID Number: 0xa000cb3c 0x006c4757
Serial Number: 0x00000000 0x00000000 0x14d463dc 0x2f908de1
In the log section at the bottom in gnuradio-companion, HackRFOne is not displaying after debugging as an execute device.
Is there a problem with VID and PID of new versions and old hardware versions — for example statically hard-coded numbers in gnuradio-companion? D
I see this device:
Bus 002 Device 021: ID 1d50:6089 OpenMoko, Inc.
Where is the problem?
In the source code for GNU-Radio Companion, in which file/files can I edit information for detecting HackRFOne hardware?
Sorry, it's ok, I make upgrade from Fedora 20 to Fedora 21 and it's fine!