Using Orbbec Embedded S camera from ARM with OpenNI - arm

I have an ARM SoC that I've connected an Embedded S camera to. I can see the camera is connected:
$ lsusb
Bus 001 Device 006: ID 2bc5:050b
Bus 001 Device 007: ID 2bc5:060b
I downloaded OpenNI_2.3.0.63.zip from https://orbbec3d.com/develop/ then copied the OpenNI-Linux-Arm64-2.3.0.63 directory to my device and ran install.sh. Now when I plug in the camera I get:
[ 5887.390778] hub 1-1:1.0: 2 ports detected
[ 5887.879656] usb 1-1.1: New USB device found, idVendor=2bc5, idProduct=050b
[ 5887.886538] usb 1-1.1: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[ 5887.894193] usb 1-1.1: Product: USB 2.0 Camera
[ 5887.898757] usb 1-1.1: Manufacturer: Sonix Technology Co., Ltd.
[ 5887.904814] usb 1-1.1: SerialNumber: SN0001
[ 5888.232284] usb 1-1.2: New USB device found, idVendor=2bc5, idProduct=060b
[ 5888.239161] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5888.246856] usb 1-1.2: Product: ORBBEC Depth Sensor
[ 5888.251853] usb 1-1.2: Manufacturer: Orbbec(R)
I cross-compiled a simple app:
int main(int argc, char** argv)
{
const char* deviceURI = openni::ANY_DEVICE;
Status result = STATUS_OK;
result = OpenNI::initialize();
cout << "OpenNI::initialize() = " << result << endl;
openni::Array<openni::DeviceInfo> deviceList;
openni::OpenNI::enumerateDevices(&deviceList);
cout << "OpenNI::enumerateDevices() = " << deviceList.getSize() << endl;
for (int i = 0; i < deviceList.getSize(); ++i)
{
cout << "Device " << deviceList[i].getUri() << " already connected" << endl;
}
When I ran it first I got:
error while loading shared libraries: libOpenNI2.so: cannot open shared object file: No such file or director
So I copied libOpenNI2.so to /usr/lib. Now when I run it I get:
OpenNI::initialize() = 1
OpenNI::enumerateDevices() = 0
Why isn't the camera being seen? Is there something else I have to do to get it to work?

I turned on logging using:
OpenNI::setLogMinSeverity(0);
OpenNI::setLogConsoleOutput(true);
and saw:
3774 INFO Log XnLog.cpp 349 New log started on 2019-11-25 09:57:11
3864 INFO Log XnLog.cpp 322 --- Filter Info --- Minimum Severity: VERBOSE
4044 VERBOSE OniContext OniContext.cpp 165 OpenNI 2.3.0 (Build 63)-Linux-Arm (May 13 2019 17:45:57)
4089 VERBOSE OniContext OniContext.cpp 259 Using '/usr/lib/OpenNI2/Drivers' as driver path
4112 VERBOSE OniContext OniContext.cpp 267 Looking for drivers at '/usr/lib/OpenNI2/Drivers'
4167 ERROR OniContext OniContext.cpp 279 Found no drivers matching '/usr/lib/OpenNI2/Drivers/lib*.so'
So I copied the files from OpenNI-Linux-Arm64-2.3.0.63/Redist/OpenNI2/Drivers/ to /usr/lib/OpenNI2/Drivers/. The Readme also says:
*for using with Astra Embedded S/Stereo S, please change the resolution in 'orbbec.ini' to 'Resolution=17' for Depth and IR streams
So I edited this in /usr/lib/OpenNI2/Drivers/orbbec.ini. Now I get:
3924 INFO Log XnLog.cpp 349 New log started on 2019-11-25 10:23:55
4010 INFO Log XnLog.cpp 322 --- Filter Info --- Minimum Severity: VERBOSE
4185 VERBOSE OniContext OniContext.cpp 165 OpenNI 2.3.0 (Build 63)-Linux-Arm (May 13 2019 17:45:57)
4230 VERBOSE OniContext OniContext.cpp 259 Using '/usr/lib/OpenNI2/Drivers' as driver path
4254 VERBOSE OniContext OniContext.cpp 267 Looking for drivers at '/usr/lib/OpenNI2/Drivers'
4547 VERBOSE OniContext OniContext.cpp 309 Loading device driver 'libOniFile.so'...
4588 WARNING xnOS XnLinuxSharedLibs.cpp 107 loading lib from: /usr/lib/OpenNI2/Drivers/libOniFile.so
6199 VERBOSE OniContext OniContext.cpp 309 Loading device driver 'libPSLink.so'...
6240 WARNING xnOS XnLinuxSharedLibs.cpp 107 loading lib from: /usr/lib/OpenNI2/Drivers/libPSLink.so
11412 WARNING DriverHandler OniDriverHandler.cpp 85 LibraryHandler: Couldn't find function oniDriverStreamConvertC2DCoordinates in libPSLink.so. Stopping
11539 WARNING OniContext OniContext.cpp 313 Couldn't use file 'libPSLink.so' as a device driver
11626 VERBOSE OniContext OniContext.cpp 309 Loading device driver 'liborbbec.so'...
11675 WARNING xnOS XnLinuxSharedLibs.cpp 107 loading lib from: /usr/lib/OpenNI2/Drivers/liborbbec.so
15571 INFO Log XnLog.cpp 349 New log started on 2019-11-25 10:23:55
15615 INFO Log XnLog.cpp 322 --- Filter Info --- Minimum Severity: VERBOSE
15645 VERBOSE xnUSB XnLinuxUSB.cpp 383 Initializing USB...
19162 INFO xnUSB XnLinuxUSB.cpp 412 USB is initialized.
OpenNI::initialize() = 0
OpenNI::enumerateDevices() = 0
which is better but still not successful. I then realised that I hadn't reconnected the camera after copying the driver files so I did that and it worked.

Related

EFI Application Erorr Write Protected

I tried to do some write/read operations on filesystems that I have enumerated for. The problem is when I want to write to other volumes rather than my self (fs0), it will return WRITE PROTECTED Error.
... Enumerated and opened all available volumes successfuly
efiStatus = root->Open(root, &token, L"xxx", EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE | EFI_FILE_MODE_CREATE, 0);
if (efiStatus == EFI_SUCCESS)
{
char* myStr = "Sample Content";
UINTN myStrSize = strlenEx(myStr);
efiStatus = token->Write(token, &myStrSize, myStr);
if (efiStatus != EFI_SUCCESS)
{
Print(L"[X] ! Error [%r]!\n", efiStatus);
}
Print(L"Found Some\n", efiStatus);
}
I Also tried ShellCreateDirectory, ShellWriteFile. Do I really can access write hard disk (pci) from EFI Application?
EDIT:
drivers command output:
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
43 00000014 D - - 1 - AMI USB Driver Uhcd
45 00000014 B - - 1 4 USB bus Uhcd
46 00000002 D - - 3 - USB Hid driver Uhcd
47 00000001 D - - 1 - USB Mass Storage driver Uhcd
85 00010000 ? - - - - AMI ExFat Driver EXFAT
86 00010000 D - - 5 - AMI NTFS Driver NTFS
89 00000001 D - - 2 - <null string> MouseDriver
8B 00000001 B - - 1 3 AMI AHCI BUS Driver Ahci
8F 00000001 ? - - - - AMI NVMe BUS Driver Nvme
123 00000010 D - - 1 - Serial ATA Controller Initializatio SataController
12E 00000010 B - - 1 1 AMI Console Splitter Text Out Drive ConSplitter
12F 00000010 B - - 1 1 AMI Console Splitter Text In Driver ConSplitter
130 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
133 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
134 0000000A D - - 15 - Generic Disk I/O Driver DiskIoDxe
135 0000000B B - - 3 11 Partition Driver(MBR/GPT/El Torito) PartitionDxe
137 00000000 ? - - - - Integrated Touch Driver IntegratedTouch
13A 00000010 B - - 1 5 AMI Generic LPC Super I/O Driver GenericSio
13C 00A50110 B - - 1 15 AMI PCI Bus Driver PciBus
13E 00000010 ? - - - - AMI PS/2 Driver Ps2Main
13F 00000000 ? - - - - DNS Network Service Driver DnsDxe
140 00000000 ? - - - - DNS Network Service Driver DnsDxe
145 0000000A D - - 2 - FAT File System Driver Fat
147 00010001 ? - - - - AMI ISO9660 File System Driver FsIso9660
149 00000001 ? - - - - <null string> PcieSataController
14A 00000001 ? - - - - <null string> PcieSataController
14B 0000001B B - - 1 3 Intel(R) RST 16.0.2.3402 RAID Drive RaidDriver
159 09000432 B - - 1 1 Intel(R) GOP Driver [9.0.1074] MemoryMapped(0x3,0x845F3018,0x846040D8)
My educated guess is that you trying to access NTFS volume (since you talked about Windows partitions) and NTFS is not supported by UEFI (by default). At least, I haven't seen any firmware that does. UEFI supports FAT32 file systems only.
If you drop into UEFI shell on your platform you should see the "Mapping table" (see the sample picture below), if there is a device labeled "FS0". This indicates that the firmware detected the disk, discovered the partition, and was able to mount the file system. The rest of the volumes labeled as BLK, which means UEFI can give the access using BlockIO Protocol only. No FS Protocol support.

New PocketSphinx user: "Segmentation fault: 11" error upon following official getting started guide

I am a new PocketSphinx user. I just followed the official getting started guide
However, I begin having difficulties when I get to this step:
"To test the installation, run pocketsphinx_continuous -inmic yes and check that it recognizes words you speak into your microphone."
I've attached my terminal output that I receive when I type this command, which ultimately results in 'Segmentation fault: 11'
Any help would be greatly appreciated.
Thanks,
Nakul
nakul : ~ 101 $ pocketsphinx_continuous -inmic yes
INFO: pocketsphinx.c(152): Parsed model-specific feature parameters from /usr/local/share/pocketsphinx/model/en-us/en-us/feat.params
Current configuration:
[NAME] [DEFLT] [VALUE]
-agc none none
-agcthresh 2.0 2.000000e+00
-allphone
-allphone_ci no no
-alpha 0.97 9.700000e-01
-ascale 20.0 2.000000e+01
-aw 1 1
-backtrace no no
-beam 1e-48 1.000000e-48
-bestpath yes yes
-bestpathlw 9.5 9.500000e+00
-ceplen 13 13
-cmn live batch
-cmninit 40,3,-1 41.00,-5.29,-0.12,5.09,2.48,-4.07,-1.37,-1.78,-5.08,-2.05,-6.45,-1.42,1.17
-compallsen no no
-debug 0
-dict /usr/local/share/pocketsphinx/model/en-us/cmudict-en-us.dict
-dictcase no no
-dither no no
-doublebw no no
-ds 1 1
-fdict
-feat 1s_c_d_dd 1s_c_d_dd
-featparams
-fillprob 1e-8 1.000000e-08
-frate 100 100
-fsg
-fsgusealtpron yes yes
-fsgusefiller yes yes
-fwdflat yes yes
-fwdflatbeam 1e-64 1.000000e-64
-fwdflatefwid 4 4
-fwdflatlw 8.5 8.500000e+00
-fwdflatsfwin 25 25
-fwdflatwbeam 7e-29 7.000000e-29
-fwdtree yes yes
-hmm /usr/local/share/pocketsphinx/model/en-us/en-us
-input_endian little little
-jsgf
-keyphrase
-kws
-kws_delay 10 10
-kws_plp 1e-1 1.000000e-01
-kws_threshold 1 1.000000e+00
-latsize 5000 5000
-lda
-ldadim 0 0
-lifter 0 22
-lm /usr/local/share/pocketsphinx/model/en-us/en-us.lm.bin
-lmctl
-lmname
-logbase 1.0001 1.000100e+00
-logfn
-logspec no no
-lowerf 133.33334 1.300000e+02
-lpbeam 1e-40 1.000000e-40
-lponlybeam 7e-29 7.000000e-29
-lw 6.5 6.500000e+00
-maxhmmpf 30000 30000
-maxwpf -1 -1
-mdef
-mean
-mfclogdir
-min_endfr 0 0
-mixw
-mixwfloor 0.0000001 1.000000e-07
-mllr
-mmap yes yes
-ncep 13 13
-nfft 512 512
-nfilt 40 25
-nwpen 1.0 1.000000e+00
-pbeam 1e-48 1.000000e-48
-pip 1.0 1.000000e+00
-pl_beam 1e-10 1.000000e-10
-pl_pbeam 1e-10 1.000000e-10
-pl_pip 1.0 1.000000e+00
-pl_weight 3.0 3.000000e+00
-pl_window 5 5
-rawlogdir
-remove_dc no no
-remove_noise yes yes
-remove_silence yes yes
-round_filters yes yes
-samprate 16000 1.600000e+04
-seed -1 -1
-sendump
-senlogdir
-senmgau
-silprob 0.005 5.000000e-03
-smoothspec no no
-svspec 0-12/13-25/26-38
-tmat
-tmatfloor 0.0001 1.000000e-04
-topn 4 4
-topn_beam 0 0
-toprule
-transform legacy dct
-unit_area yes yes
-upperf 6855.4976 6.800000e+03
-uw 1.0 1.000000e+00
-vad_postspeech 50 50
-vad_prespeech 20 20
-vad_startspeech 10 10
-vad_threshold 2.0 2.000000e+00
-var
-varfloor 0.0001 1.000000e-04
-varnorm no no
-verbose no no
-warp_params
-warp_type inverse_linear inverse_linear
-wbeam 7e-29 7.000000e-29
-wip 0.65 6.500000e-01
-wlen 0.025625 2.562500e-02
INFO: feat.c(715): Initializing feature stream to type: '1s_c_d_dd', ceplen=13, CMN='batch', VARNORM='no', AGC='none'
INFO: acmod.c(162): Using subvector specification 0-12/13-25/26-38
INFO: mdef.c(518): Reading model definition: /usr/local/share/pocketsphinx/model/en-us/en-us/mdef
INFO: mdef.c(531): Found byte-order mark BMDF, assuming this is a binary mdef file
INFO: bin_mdef.c(336): Reading binary model definition: /usr/local/share/pocketsphinx/model/en-us/en-us/mdef
INFO: bin_mdef.c(516): 42 CI-phone, 137053 CD-phone, 3 emitstate/phone, 126 CI-sen, 5126 Sen, 29324 Sen-Seq
INFO: tmat.c(149): Reading HMM transition probability matrices: /usr/local/share/pocketsphinx/model/en-us/en-us/transition_matrices
INFO: acmod.c(113): Attempting to use PTM computation module
INFO: ms_gauden.c(127): Reading mixture gaussian parameter: /usr/local/share/pocketsphinx/model/en-us/en-us/means
INFO: ms_gauden.c(242): 42 codebook, 3 feature, size:
INFO: ms_gauden.c(244): 128x13
INFO: ms_gauden.c(244): 128x13
INFO: ms_gauden.c(244): 128x13
INFO: ms_gauden.c(127): Reading mixture gaussian parameter: /usr/local/share/pocketsphinx/model/en-us/en-us/variances
INFO: ms_gauden.c(242): 42 codebook, 3 feature, size:
INFO: ms_gauden.c(244): 128x13
INFO: ms_gauden.c(244): 128x13
INFO: ms_gauden.c(244): 128x13
INFO: ms_gauden.c(304): 222 variance values floored
INFO: ptm_mgau.c(476): Loading senones from dump file /usr/local/share/pocketsphinx/model/en-us/en-us/sendump
INFO: ptm_mgau.c(500): BEGIN FILE FORMAT DESCRIPTION
INFO: ptm_mgau.c(563): Rows: 128, Columns: 5126
INFO: ptm_mgau.c(595): Using memory-mapped I/O for senones
INFO: ptm_mgau.c(838): Maximum top-N: 4
INFO: phone_loop_search.c(114): State beam -225 Phone exit beam -225 Insertion penalty 0
INFO: dict.c(320): Allocating 138824 * 32 bytes (4338 KiB) for word entries
INFO: dict.c(333): Reading main dictionary: /usr/local/share/pocketsphinx/model/en-us/cmudict-en-us.dict
INFO: dict.c(213): Dictionary size 134723, allocated 1016 KiB for strings, 1679 KiB for phones
INFO: dict.c(336): 134723 words read
INFO: dict.c(358): Reading filler dictionary: /usr/local/share/pocketsphinx/model/en-us/en-us/noisedict
INFO: dict.c(213): Dictionary size 134728, allocated 0 KiB for strings, 0 KiB for phones
INFO: dict.c(361): 5 words read
INFO: dict2pid.c(396): Building PID tables for dictionary
INFO: dict2pid.c(406): Allocating 42^3 * 2 bytes (144 KiB) for word-initial triphones
INFO: dict2pid.c(132): Allocated 42672 bytes (41 KiB) for word-final triphones
INFO: dict2pid.c(196): Allocated 42672 bytes (41 KiB) for single-phone word triphones
INFO: ngram_model_trie.c(354): Trying to read LM in trie binary format
INFO: ngram_search_fwdtree.c(74): Initializing search tree
INFO: ngram_search_fwdtree.c(101): 791 unique initial diphones
INFO: ngram_search_fwdtree.c(186): Creating search channels
INFO: ngram_search_fwdtree.c(323): Max nonroot chan increased to 152609
INFO: ngram_search_fwdtree.c(333): Created 723 root, 152481 non-root channels, 53 single-phone words
INFO: ngram_search_fwdflat.c(157): fwdflat: min_ef_width = 4, max_sf_win = 25
INFO: continuous.c(307): pocketsphinx_continuous COMPILED ON: Sep 6 2018, AT: 19:28:29
INFO: continuous.c(252): Ready....
Segmentation fault: 11
nakul : ~ 102 $ defaults write com.apple.finder AppleShowAllFiles YES.

Automatically attaching to process on SEGV and other fatal signals (panic_action)

Background
Code to support a 'panic_action' was recently added to the FreeRADIUS v3.0.x, v2.0.x and master branches.
When radiusd (main FreeRADIUS process) receives a fatal signal (SIGFPE, SIGABRT, SIGSEGV etc...), the signal handler executes a predefined 'panic_action' which is a snippet of shell code passed to system(). The signal handler performs basic substitution for %e and %p writing in the values of the current binary name, and the current PID.
This should in theory allow a debugger like gdb or lldb to attach to the process (panic_action = lldb -f %e -p %p), either to perform interactive debugging, or to automate collection of a backtrace. This actually works well on my system OSX 10.9.2 with lldb, but only for SIGABRT.
Problem
This doesn't seem to work for other signals like SIGSEGV. The mini backtrace from execinfo is valid, but when lldb or gdb attach to the process, they only get the backtrace from for the signal handler.
There doesn't seem to be a way in lldb to switch to an arbitrary frame address.
Does anyone know if there's any way of forcing the signal handler to execute in the same stack as the the thread that received the signal? Or why when lldb attaches the backtraces don't show the full stack.
The actual output looks like:
FATAL SIGNAL: Segmentation fault: 11
Backtrace of last 12 frames:
0 libfreeradius-radius.dylib 0x000000010cf1f00f fr_fault + 127
1 libsystem_platform.dylib 0x00007fff8b03e5aa _sigtramp + 26
2 radiusd 0x000000010ce7617f do_compile_modsingle + 3103
3 libfreeradius-server.dylib 0x000000010cef3780 fr_condition_walk + 48
4 radiusd 0x000000010ce7710f modcall_pass2 + 191
5 radiusd 0x000000010ce7713f modcall_pass2 + 239
6 radiusd 0x000000010ce7078d virtual_servers_load + 685
7 radiusd 0x000000010ce71df1 setup_modules + 1633
8 radiusd 0x000000010ce6daae read_mainconfig + 2526
9 radiusd 0x000000010ce78fe6 main + 1798
10 libdyld.dylib 0x00007fff8580a5fd start + 1
11 ??? 0x0000000000000002 0x0 + 2
Calling: lldb -f /usr/local/freeradius/sbin/radiusd -p 1397
Current executable set to '/usr/local/freeradius/sbin/radiusd' (x86_64).
Attaching to process with:
process attach -p 1397
Process 1397 stopped
(lldb) bt
error: libfreeradius-radius.dylib debug map object file '/Users/arr2036/Documents/Repositories/freeradius-server-fork/build/objs//Users/arr2036/Documents/Repositories/freeradius-server-master/src/lib/debug.o' has changed (actual time is 0x530f3d21, debug map time is 0x530f37a5) since this executable was linked, file will be ignored
* thread #1: tid = 0x8d824, 0x00007fff867fee38 libsystem_kernel.dylib`wait4 + 8, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
frame #0: 0x00007fff867fee38 libsystem_kernel.dylib`wait4 + 8
frame #1: 0x00007fff82869090 libsystem_c.dylib`system + 425
frame #2: 0x000000010cf1f2e1 libfreeradius-radius.dylib`fr_fault + 849
frame #3: 0x00007fff8b03e5aa libsystem_platform.dylib`_sigtramp + 26
(lldb)
Code
The relevant code for fr_fault() is here:https://github.com/FreeRADIUS/freeradius-server/blob/b7ec8c37c7204accbce4be4de5013397ab662ea3/src/lib/debug.c#L227
and fr_set_signal() the function used to setup signal handlers is here: https://github.com/FreeRADIUS/freeradius-server/blob/0cf0e88704228e8eac2948086e2ba2f4d17a5171/src/lib/misc.c#L61
As the links contain commit hashes the code should be static
EDIT
Finally with version lldb-330.0.48 on OSX 10.10.4 lldb can now go past _sigtram.
frame #2: 0x000000010b96c5f7 libfreeradius-radius.dylib`fr_fault(sig=11) + 983 at debug.c:735
732 FR_FAULT_LOG("Temporarily setting PR_DUMPABLE to 1");
733 }
734
-> 735 code = system(cmd);
736
737 /*
738 * We only want to error out here, if dumpable was originally disabled
(lldb)
frame #3: 0x00007fff8df77f1a libsystem_platform.dylib`_sigtramp + 26
libsystem_platform.dylib`_sigtramp:
0x7fff8df77f1a <+26>: decl -0x16f33a50(%rip)
0x7fff8df77f20 <+32>: movq %rbx, %rdi
0x7fff8df77f23 <+35>: movl $0x1e, %esi
0x7fff8df77f28 <+40>: callq 0x7fff8df794d8 ; symbol stub for: __sigreturn
(lldb)
frame #4: 0x000000010bccb027 rlm_json.dylib`_json_map_proc_get_value(ctx=0x00007ffefa62dbe0, out=0x00007fff543534b8, request=0x00007ffefa62da30, map=0x00007ffefa62aaf0, uctx=0x00007fff54353688) + 391 at rlm_json.c:191
188 }
189 vp = map->op;
190
-> 191 if (value_data_steal(vp, &vp->data, vp->da->type, value) < 0) {
192 REDEBUG("Copying data to attribute failed: %s", fr_strerror());
193 talloc_free(vp);
194 goto error;
This is a bug in lldb related to backtracing through _sigtramp, the asynchronous signal handler in user processes. Unfortunately I can't suggest a workaround for this problem. It has been fixed in the top of tree sources for lldb at http://lldb.llvm.org/ if you're willing to build from source (see the "Source" and "Build" sidebars). But Xcode 5.0 and the next dot release are going to have real problems backtracing past _sigtramp.

Segmentation fault as soon the binary launch

How to debug a segmentation fault caused by launching the binary on Linux?
No source code is available for the binary.
How to know the system calls made by the binary which caused the seg fault. Is there any debugging utility that might help?
In addition to what's been suggested you can also do the following:
Run ulimit -c unlimited to enable core dumping, then run your app.
At the point of segfaulting it should do a core dump.
Then you can run gdb your_app core and inside gdb run backtrace. Maybe it's been compiled with debugging symbols so you actually get quite a bit of information out.
Does strace your-program help you? It will print a list of all system calls called by your program.
Sample Output
% strace true
.
2 2 [main] true (2064) **********************************************
83 85 [main] true (2064) Program name: C:\cygwin\bin\true.exe (windows pid 2064)
44 129 [main] true (2064) OS version: Windows NT-6.1
36 165 [main] true (2064) **********************************************
145 310 [main] true (2064) sigprocmask: 0 = sigprocmask (0, 0x6123D468, 0x610FBA10)
183 493 [main] true 2064 open_shared: name shared.5, n 5, shared 0x60FF0000 (wanted 0x60FF0000), h 0x70, *m 6
27 520 [main] true 2064 heap_init: heap base 0x20000000, heap top 0x20000000, heap size 0x18000000 (402653184)
30 550 [main] true 2064 open_shared: name foo, n 1, shared 0x60FE0000 (wanted 0x60FE0000), h 0x68, *m 6
18 568 [main] true 2064 user_info::create: opening user shared for 'foo' at 0x60FE0000
17 585 [main] true 2064 user_info::create: user shared version 6467403B
36 621 [main] true 2064 fhandler_pipe::create: name \\.\dir\cygwin-c5e39b7a9d22bafb-2064-sigwait, size 164, mode PIPE_TYPE_MESSAGE
51 672 [main] true 2064 fhandler_pipe::create: pipe read handle 0x84
16 688 [main] true 2064 fhandler_pipe::create: CreateFile: name \\.\dir\cygwin-c5e39b7a9d22bafb-2064-sigwait
35 723 [main] true 2064 fhandler_pipe::create: pipe write handle 0x88
23 746 [main] true 2064 dll_crt0_0: finished dll_crt0_0 initialization

UBIFS boot error

I have a SAM9 based board running embedded linux.
I had a JFFS2 file system and now thinking of moving to UBIFS.
I enabled UBIFS as target file system in make menuconfig of buildroot package which I'm using for my board.
I generated the rootfs.arm.ubifs file which I flashed on my board using nandwrite utility of bootloader the same way which I was using for .jffs2 file.
I also changed the bootargs to :
setenv bootargs 'console=ttyS0,115200 rw ubi.mtd=1,2048 rootfstype=ubifs root=ubi0:rootfs'
But I'm getting the following error which booting the board :
Creating 2 MTD partitions on "atmel_nand":
0x000000000000-0x000000400000 : "Kernel"
0x000000400000-0x000010000000 : "Data"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI warning: ubi_scan: 276 PEBs are corrupted
corrupted PEBs are: 0 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 517
UBI error: ubi_read_volume_table: the layout volume was not found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
This is a guess, but did you ubinize your rootfs before flashing it onto the raw NAND?
From http://www.linux-mtd.infradead.org/doc/ubifs.html#L_usptools
The images produced by mkfs.ubifs may be written to UBI volumes using
ubiupdatevol or may be further fed to the ubinize tool to create an UBI
image which may be put to the raw flash.

Resources