OpenCores
no use no use 1/1 no use no use
linux lseek call problem
by hwmin75 on Mar 29, 2012
hwmin75
Posts: 20
Joined: Mar 8, 2010
Last seen: Jul 21, 2018
we added our SDHC in openrisc cpu, and made SDHC linux driver which is based on ordb2 platform.
However, we found openrisc linux can't support 2G OVER file size.
we can't format sd card over 4G int FAT32.

/ # mkfs.vfat /dev/mmcblk0p1
fs/read_write.c generic_file_llseek 118
fs/read_write.c generic_file_llseek_unlocked 55
retval ec57e000, res ec57e000
mkfs.vfat: lseek: Value too large for defined data type

we checked linux and busybox configuration which can support LFS(long file system)

we analyzed problem that is linux's lseek system call.
lseek call only support 32-bits return value.

However, ARM linux's lseek can support 64-bits return value.
ARM Linux's kernel version is 2.6.31 and Our linux is 3.1.

How we can solve this problem ?


RE: linux lseek call problem
by jb007 on Mar 29, 2012
jb007
Posts: 29
Joined: May 3, 2009
Last seen: Jun 29, 2020
Hi. I'm not a Linux guru, but a quick look at the linux manual for lseek shows that it can support 64bit return values. See http://linux.die.net/man/3/lseek64 especially the section that says:

lseek(2) uses the type off_t. This is a 32-bit signed type on 32-bit architectures, unless one compiles with
#define _FILE_OFFSET_BITS 64
in which case it is a 64-bit signed type.


On another note, will your Linux SD driver for the Ordb2 be made public, as I have been trying to find someone to help with a driver in this thread: http://opencores.org/forum,OpenRISC,0,4669

Look forward to you resolving your issues, and hopefully providing a driver for me, and others!

Jim
RE: linux lseek call problem
by hwmin75 on Mar 29, 2012
hwmin75
Posts: 20
Joined: Mar 8, 2010
Last seen: Jul 21, 2018
First, Thank you for your Replay.

I used lseek64 function already and it apply to busybox 1.92 . but the result is equal to lseek.

I'm sorry for providing sd driver. our sdhc is not for ordb2 board.
and our driver is not helpful for you.

I'm assume that our problem fo lseek is related to system call porting.


RE: linux lseek call problem
by hwmin75 on Apr 13, 2012
hwmin75
Posts: 20
Joined: Mar 8, 2010
Last seen: Jul 21, 2018
I solved my problem for lseek() call.

The followings is a patch.


>> linux kernel.
===================================================

1. include/asm-gerneric/unistd.h
--- a/include/asm-generic/unistd.h
+++ b/include/asm-generic/unistd.h
@@ -198,8 +198,7 @@ __SC_COMP(__NR_getdents64, sys_getdents64, compat_sys_getdents64)
 
 /* fs/read_write.c */
 #define __NR3264_lseek 62
-//__SC_3264(__NR3264_lseek, sys_llseek, sys_lseek)
-__SYSCALL(__NR3264_lseek, sys_llseek)
+__SC_3264(__NR3264_lseek, sys_llseek, sys_lseek)
 #define __NR_read 63
 __SYSCALL(__NR_read, sys_read)
 #define __NR_write 64
@@ -780,8 +779,8 @@ __SYSCALL(__NR_newfstatat, sys_newfstatat)
 __SYSCALL(__NR_fstatfs, sys_fstatfs)
 #define __NR_statfs 1056
 __SYSCALL(__NR_statfs, sys_statfs)
-#define __NR_lseek 1057
-__SYSCALL(__NR_lseek, sys_lseek) //for test.
+//#define __NR_lseek 1057
+//__SYSCALL(__NR_lseek, sys_lseek)
 #define __NR_mmap 1058
 __SYSCALL(__NR_mmap, sys_mmap)

2. /arch/openrisc/include/asm/unistd.h
--- a/arch/openrisc/include/asm/unistd.h
+++ b/arch/openrisc/include/asm/unistd.h
@@ -35,4 +35,9 @@
 #define __NR_or1k_atomic __NR_arch_specific_syscall
 __SYSCALL(__NR_or1k_atomic, sys_or1k_atomic)
 
+#define __NR__llseek (__NR_arch_specific_syscall+1)
+__SYSCALL(__NR__llseek, sys_llseek)
+
+

>> uClibc
================================================
 uClibc/libc/sysdeps/linux/common/llseek.c
--- a/uClibc/libc/sysdeps/linux/common/llseek.c
+++ b/uClibc/libc/sysdeps/linux/common/llseek.c
@@ -15,9 +15,12 @@
 
 loff_t lseek64(int fd, loff_t offset, int whence)
 {
-       loff_t result;
-       return (loff_t)(INLINE_SYSCALL(_llseek, 5, fd, (off_t) (offset >> 32),
+       loff_t result,ret;
+       
+       ret = (INLINE_SYSCALL(_llseek, 5, fd, (off_t) (offset >> 32),
                                (off_t) (offset & 0xffffffff), &result, whence) ?: result);
+       
+       return result;
 }
RE: linux lseek call problem
by hwmin75 on Apr 13, 2012
hwmin75
Posts: 20
Joined: Mar 8, 2010
Last seen: Jul 21, 2018
I solved my problem for lseek() call.

The followings is a patch.


>> linux kernel.

--- a/arch/openrisc/include/asm/unistd.h
+++ b/arch/openrisc/include/asm/unistd.h
@@ -35,4 +35,9 @@
#define __NR_or1k_atomic __NR_arch_specific_syscall
__SYSCALL(__NR_or1k_atomic, sys_or1k_atomic)

+#define __NR__llseek (__NR_arch_specific_syscall+1)
+__SYSCALL(__NR__llseek, sys_llseek)
+
+
+
#endif /* __ASM_OPENRISC_UNISTD_H */

--- a/include/asm-generic/unistd.h
+++ b/include/asm-generic/unistd.h
@@ -198,8 +198,7 @@ __SC_COMP(__NR_getdents64, sys_getdents64, compat_sys_getdents64)

/* fs/read_write.c */
#define __NR3264_lseek 62
-//__SC_3264(__NR3264_lseek, sys_llseek, sys_lseek)
-__SYSCALL(__NR3264_lseek, sys_llseek)
+__SC_3264(__NR3264_lseek, sys_llseek, sys_lseek)
#define __NR_read 63
__SYSCALL(__NR_read, sys_read)
#define __NR_write 64
@@ -780,8 +779,8 @@ __SYSCALL(__NR_newfstatat, sys_newfstatat)
__SYSCALL(__NR_fstatfs, sys_fstatfs)
#define __NR_statfs 1056
__SYSCALL(__NR_statfs, sys_statfs)
-#define __NR_lseek 1057
-__SYSCALL(__NR_lseek, sys_lseek) //for test.
+//#define __NR_lseek 1057
+//__SYSCALL(__NR_lseek, sys_lseek)
#define __NR_mmap 1058
__SYSCALL(__NR_mmap, sys_mmap)

>> uClibc
=====================================================
--- a/uClibc/libc/sysdeps/linux/common/llseek.c
+++ b/uClibc/libc/sysdeps/linux/common/llseek.c
@@ -15,9 +15,12 @@

loff_t lseek64(int fd, loff_t offset, int whence)
{
- loff_t result;
- return (loff_t)(INLINE_SYSCALL(_llseek, 5, fd, (off_t) (offset >> 32),
+ loff_t result,ret;
+
+ ret = (INLINE_SYSCALL(_llseek, 5, fd, (off_t) (offset >> 32),
(off_t) (offset & 0xffffffff), &result, whence) ?: result);
+
+ return result;
}

#else
no use no use 1/1 no use no use
© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.