I'm facing two problems on mounting jffs2 on NOR flash:
I'm running a board with squashfs as rootfs and I tried to mount jffs2 on another mtdblock as below :
mount -t jffs2 /dev/mtdblock6 /tmp/jffs
After that I copy some files into /tmp/jffs but system gives the error when the files larger than 4096 bytes:
cp: write error: Input/output error
Then I unmount the mtdblock and re-mount it again, but the files I just copied has disappeared.
I confirmed the flash block has been written by dumping /dev/mtd6 or /dev/mtdblock6, but those files cannot be seen after remounting.
=====
I opened the printk log and have following message showed up when I put a file in mounted folder:
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00120814: 0x0219 instead
Node totlen on flash (0x0000000c) != totlen from node ref (0x00000044)
and below message appeared when I tried to re-mount the mtdblock:
JFFS2 notice: (608) jffs2_get_inode_nodes: Node header CRC failed at 0x0e0050. {0000,9600,01e88b11,01000000}
Very appreciate if there is any suggestion.
Related
I have a SSD and a HDD in my system.I am using ssd for store ubuntu and windows and saving my project files in HDD. But i flutter cant access files in the HDD.
It is throwing this error message
Oops; flutter has exited unexpectedly: "FileSystemException: Cannot delete file,
path = '/path to project/.flutter-plugins' (OS Error:
Read-only file system, errno = 30)".
Unable to generate crash report due to secondary error: FileSystemException: Cannot create file, path = '/path to project/flutter_01.log' (OS Error: Read-only file system, errno = 30)
Please report a bug at https://github.com/flutter/flutter/issues.
Oops; flutter has exited unexpectedly: "FileSystemException: Cannot delete file,
path = '/path to project/.flutter-plugins' (OS Error:
Read-only file system, errno = 30)".
Unable to generate crash report due to secondary error: FileSystemException: Cannot create file, path = '/path to project/flutter_01.log' (OS Error: Read-only file system, errno = 30)
Please report a bug at https://github.com/flutter/flutter/issues.
Unhandled exception:
ProcessExit: 1
#0 _handleToolError (package:flutter_tools/runner.dart:172:7)
#1 run.. (package:flutter_tools/runner.dart:86:7)
My secondary harddisk was mounting as read only file system.
I have remounted it to solve the issue.
I am getting attached error while creating Gluster cluster on Kubernetes. Can someone please advice why this error is coming and how to resolve it?
This is solved by by using the command wipefs -a /dev/sdb1. It wipes the signature present on newly created partition.
I spend a few days trying to understand but I'm stuck.
I get no more than a "Starting kernel..." message after entering 'bootm 8100000' on my STM32F429I-DISC1 board.
Before I update uboot from 2011 to 2016 It was a "Starting Kernel..." + UNHANDED EXCEPTION HARDFAULT, but now I have just the "Starting Kernel..." message.
MCU is a stm32F429, 2MB Flash + ext. 8MB RAM.
Flash start addr is 0x08000000 (uboot addr) and I put my kernel on the start of the 2nd flash bank at 0x08100000.
Start of External 8MB RAM is 0xD0000000
u-boot-2016.11 seems to run pretty well on that board, bdi give me:
U-Boot > bdi
arch_number = 0x00000000
boot_params = 0xD0000100
DRAM bank = 0x00000000
-> start = 0xD0000000
-> size = 0x00800000
current eth = unknown
ip_addr = <NULL>
baudrate = 115200 bps
relocaddr = 0xD07D6000
reloc off = 0xC87D6000
irq_sp = 0xD05D3EE0
sp start = 0xD05D3ED0
Early malloc usage: e0 / 400
This is how I build the kernel:
make CROSS_COMPILE=arm-none-eabi- ARCH=arm uImage LOADADDR=08100000 -B
And this is the complete output of bootm command:
U-Boot > bootm 8100000
## Booting kernel from Legacy Image at 08100000 ...
Image Name: Linux-4.9.0
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 839872 Bytes = 820.2 KiB
Load Address: 08100000
Entry Point: 08100000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
With the 'robutest'/'emcraft' kernel/config files I got the same log, unless the Entry Point seems more correct because it's 08100001.
On the robutest/emcraft kernel I tried to activate the LCD screen of the board, but nothing happen.
In all my test I activate kernel config "early printk" and "DEBUG_LL_xxx" stuff.
This is a link to my .config file:
http://pastebin.com/gBNYx3Gs
PS: I made some try with uCLinux emcraft/robutest to try to find what's going on, but my main goal is to run Linux 4.9.
Thanks for reading me!!!
EDIT: I tried to pass the dtb "the old way", but with the same result:
U-Boot > bootm 08100000 - 08040000
## Booting kernel from Legacy Image at 08100000 ...
Image Name: Linux-4.9.0
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 805744 Bytes = 786.9 KiB
Load Address: 08100000
Entry Point: 08100000
Verifying Checksum ... OK
## Flattened Device Tree blob at 08040000
Booting using the fdt blob at 0x8040000
Loading Kernel Image ... OK
Loading Device Tree to d05ce000, end d05d2a9f ... OK
Starting kernel ...
I'm desperate, any ideas is welcome :'(
EDIT2: I tried to uncompress the kernel with u-boot, it's the same:
U-Boot > bootm 8100000 - 8040000
## Booting kernel from Legacy Image at 08100000 ...
Image Name: uImage
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 940696 Bytes = 918.6 KiB
Load Address: d0008000
Entry Point: d0008001
Verifying Checksum ... OK
## Flattened Device Tree blob at 08040000
Booting using the fdt blob at 0x8040000
Uncompressing Kernel Image ... OK
Loading Device Tree to d05ce000, end d05d2a9f ... OK
Starting kernel ...
EDIT3: I checked the memory/USART1 address in the dtb, and it's ok. Why I have no message of the kernel?
EDIT4: With uxipImage:
U-Boot > bootm 08060000 - 08040000
## Booting kernel from Legacy Image at 08060000 ...
Image Name: uxipImage
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1497396 Bytes = 1.4 MiB
Load Address: 08060000
Entry Point: 08060041
Verifying Checksum ... OK
## Flattened Device Tree blob at 08040000
Booting using the fdt blob at 0x8040000
Loading Kernel Image ... OK
Loading Device Tree to d05ce000, end d05d2a9f ... OK
Starting kernel ...
I tried with different entry points, 08060000, 08060040 and 08060041.
I found!
Thanks alexander, the trick for the UART WORKS like a charm!!!!
Thanks to you, First time I try to hack the kernel in an embedded system and I've learnt so many things thanks to you.
For those who will have this problem, for me it was the XIP_PHYS_ADDR!
Don't forget the 64 bytes header!!
I was flashing the XIP kernel # 0x08060000 so the XIP_PHYS_ADDR (and the boot entry btw) it's 0x08060040!!!!
Thank you again alexander !!
I have had faced the same issue but the reason was a different one. The issue was in one of the u-boot structure field that stores the size of the uncompressed linux kernel. The u-boot is not populating this field with the uncompressed size, that the linux kernel uses later to resize its stack, thus putting the system into an undefined state.
Once u-boot prints the Starting kernel... message, the next message should be Uncompressing Linux... done, booting the kernel after u-boot transfers a SMM Handler for the kernel to take-over the execution, and maybe the kernel is looking for this field. If you are working on a x86 based system,the uncompression would be in the following file directories:
arch/x86/boot/uncompressed/head_32.S
arch/x86/boot/uncompressed/piggy.S
The solution is to use the latest u-boot foun in here: https://github.com/andy-shev/u-boot
However, if you are using a custom u-boot, you need to look for this field.
7:46:20 PM Gradle sync started
7:46:35 PM Gradle sync failed: Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/2.10/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Consult IDE log for more details (Help | Show Log)
the jvm version is 1.7.0_79
and the studio version is 2.1.1
Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine.
There's no space available in RAM. To fix go to /android-studio-dir/bin and edit studio.vmoptions and studio64.vmoptions to increment the -Xmx and to reserve more memory to Java. Note that the number of processes active may influence on that.
Probably, the /tmp location is full..
Found this somewhere..
Use df command
df
You should see an output with a line like this:
tmpfs 102400 102312 88 100% /tmp
So to change the size of the tmp file:
sudo mount -o remount,size=2G /tmp
Done! Now, It should work..
I am building a custom initramfs image that I am building as a CPIO archive into the Linux kernel (3.2).
The issue I am having is that no matter what I try, the kernel does not appear to even attempt to run from the initramfs.
The files I have in my CPIO archive:
cpio -it < initramfs.cpio
.
init
usr
usr/sbin
lib
lib/libcrypt.so.1
lib/libm.so
lib/libc.so.6
lib/libgcc_s.so
lib/libcrypt-2.12.2.so
lib/libgcc_s.so.1
lib/libm-2.12.2.so
lib/libc.so
lib/libc-2.12.2.so
lib/ld-linux.so.3
lib/ld-2.12.2.so
lib/libm.so.6
proc
sbin
mnt
mnt/root
root
etc
bin
bin/sh
bin/mknod
bin/mount
bin/busybox
sys
dev
4468 blocks
Init is very simple, and should just init devices and spawn a shell (for now):
#!/bin/sh
mount -t devtmpfs none /dev
mount -t proc none /proc
mount -t sysfs none /sys
/bin/busybox --install -s
exec /bin/sh
In the kernel .config I have:
CONFIG_INITRAMFS_SOURCE="../initramfs.cpio"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=32768
Kernel builds and the uImage size is larger depending on the initramfs size, so I know the image is being packed. However I get this output when I boot:
console [netcon0] enabled
netconsole: network logging started
omap_rtc omap_rtc: setting system clock to 2000-01-02 00:48:38 UTC (946774118)
Warning: unable to open an initial console.
Freeing init memory: 1252K
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SDHC card at address e624
mmcblk0: mmc0:e624 SU08G 7.40 GiB
mmcblk0: p1
Kernel panic - not syncing: Attempted to kill init!
[<c000d518>] (unwind_backtrace+0x0/0xe0) from [<c0315cf8>] (panic+0x58/0x188)
[<c0315cf8>] (panic+0x58/0x188) from [<c0021520>] (do_exit+0x98/0x6c0)
[<c0021520>] (do_exit+0x98/0x6c0) from [<c0021e88>] (do_group_exit+0xb0/0xdc)
[<c0021e88>] (do_group_exit+0xb0/0xdc) from [<c0021ec4>] (sys_exit_group+0x10/0x18)
[<c0021ec4>] (sys_exit_group+0x10/0x18) from [<c00093a0>] (ret_fast_syscall+0x0/0x2c)
From that output, it does not look like it is even trying to extract the CPIO archive as initramfs. I expect to see this printk output, which is present in linux code init/initramfs.c:
printk(KERN_INFO "Trying to unpack rootfs image as initramfs...\n");
I tried the filesystem once booting is complete (using chroot) and it works fine... so I believe the filesystem/libraries are sane.
Could anyone give me some pointers as to what I may have incorrect? Thanks in advance for any assistance!
I figured it out. I will post the answer in case anyone else has this issue.
I was missing a console device, this line was the clue:
Warning: unable to open an initial console.
After adding printk's so that I better understood the startup sequence, I realized that console device is opened prior to running the init script. Therefore, the console device must be in the initramfs filesystem directly, and we cannot rely on the devtmpfs mount to create that.
I think when the init script ran the shell was trying to open the console and failed, that's why the kernel was outputting:
Kernel panic - not syncing: Attempted to kill init!
Executing the folowing commands from within the /dev directory of initramfs on the kernel build machine will generate the required device nodes:
mknod -m 622 console c 5 1
mknod -m 622 tty0 c 4 0
After re-CPIO archiving the filesystem and rebuilding the kernel, I finally have a working filesystem in initramfs that the kernel will boot.