Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Thu Jul 19, 2018 10:42 am

All times are UTC+01:00




Post new topic  Reply to topic  [ 283 posts ]  Go to page Previous 115 16 17 18 19 Next
Author Message
PostPosted: Thu Jan 08, 2009 12:59 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
JonSenior wrote:
If you're running an Armel kernel, but your system tools are OABI, then that might be causing problems.

But Buffalo is using the same Cross-Toolchain to compile the stock kernel... just wonder if the suffix "#69" vs "#1 PREEMPT" would made any difference? Dose Marvell 88F5182 support preemption?
Quote:
version 2.6.16.16-arm1 (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #69
version 2.6.28 (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)#1 PREEMPT

Thank you for your suggestion and detailed procedures but I would prefer keep away from touching the hardware and I also like to maintain the environment as close as possible to the stock firmware.

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
PostPosted: Thu Jan 08, 2009 3:54 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
For easy comparison on differences of the 2 boot logs among the same boot sequence period:

Is that mean the new build cannot identify the LSP. I-cache & D-cache and their size?
Quote:
2.6.28
kernel:Clearing invalid memory bank 0KB@0xffffffff
last message repeated 2 times
kernel: Ignoring unrecognised tag 0x00000000
last message repeated 2 times
kernel: Ignoring unrecognised tag 0x41000403
vs
Stock
kernel: Using UBoot passing parameters structure
kernel: Sys Clk = 200000000, Tclk = 166664740
kernel:
kernel:
kernel: - Warning - This LSP release was tested only with U-Boot release 1.7.3
kernel:
kernel: Memory policy: ECC disabled, Data cache writeback
kernel: CPU0: D VIVT write-back cache
kernel: CPU0: I cache: 32768 bytes, associativity 1, 32 byte lines, 1024 sets
kernel: CPU0: D cache: 32768 bytes, associativity 1, 32 byte lines, 1024 sets
Quote:
2.6.28
kernel: PID hash table entries: 512 (order: 9, 2048 bytes)
kernel: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
kernel: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
vs
Stock
kernel: PID hash table entries: 1024 (order: 10, 16384 bytes)
kernel: Console: colour dummy device 80x30
kernel: Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
kernel: Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)

Kernel messages found from the Stock but not from the new build
Quote:
2.6.28
*** MISSING ***
vs
Stock
kernel: checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
kernel: Freeing initrd memory: 15360K
kernel: FLASH boardId = 12
kernel: Flash bankwidth 1, base ff800000, size 400000
kernel: BUFFALO LS_GL FLASH size 4096[KB]
kernel:
kernel: Marvell Development Board (LSP Version 1.7.8_NAS)-- BUFFALO_BOARD_LS_GL
kernel:
kernel: Detected Tclk 166664740 and SysClk 200000000
kernel: Marvell USB EHCI Host controller #0: c16f5e00
kernel: Marvell USB EHCI Host controller #1: c16f5c00
kernel: pexBarOverlapDetect: winNum 2 overlap current 0
kernel: mvPexInit:Warning :Bar 2 size is illigal
kernel: it will be disabled
kernel: please check Pex and CPU windows configuration
kernel: PCI: bus0: Fast back to back transfers enabled
kernel: PCI: bus1: Fast back to back transfers enabled

kernel: Initializing Cryptographic API

kernel: RAMDISK driver initialized: 3 RAM disks of 16384K size 1024 blocksize

kernel: Kernel event proc (C) BUFFALO INC. V.1.00 installed.
kernel: MICON ctrl (C) BUFFALO INC. V.1.00 installed.
kernel: MICON V2 (C) BUFFALO INC. V.1.00 installed.

Kernel messages found from the new build but not from the Stock
Quote:
2.6.28
kernel: usblp: version magic '2.6.16.16-arm1 ARMv5 gcc-3.4' should be '2.6.28 preempt mod_unload ARMv5 '

kernel: Adding 524280k swap on /mnt/disk1/mediaserver/.swap0. Priority:-1 extents:156 across:1663472k
vs
Stock
*** MISSING ***

Reason of the 1st automatically reboot is unknown, would it be due to the above missing "Kernel event proc" and "MICON ctrl"? However, system crashes near the end of the 1st reboot was triggered by XFS mount sda6 errors:
Quote:
kernel: Assertion failed: i == (ifp->if_bytes / (uint)sizeof(xfs_bmbt_rec_t)), file: fs/xfs/xfs_bmap.c, line: 4608
kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
kernel: pgd = c66a0000
kernel: [00000000] *pgd=065ae031, *pte=00000000, *ppte=00000000
kernel: Internal error: Oops: 817 [#1] PREEMPT
kernel: Modules linked in:

Seems some Buffalo specific stuff is still not available from the vanilla source? Anyone can share your Make configuration if you have made any successful port for the Linkstation Pro/Live would be much appreciated!

Sorry for the long post and thank you for your patient.

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
PostPosted: Thu Jan 08, 2009 7:32 am 
Offline
Newbie

Joined: Sat Jan 03, 2009 11:47 pm
Posts: 26
A .config file from a 2.6.28 build currently working on Linkstation Live v2 is available from http://www.hoovesofdestiny.co.uk/buffalo/.config. But I repeat that I had no success with this build until after I changed the fs type (XFS has issues under ARM) and installed the lenny rootfs. Between the stock kernels and your custom one, there is an ABI change. This will render user-space tools problematic (The compatibility layer is marked in the kernel source as experimental).

In my experience the stock system will not run with a 2.6.28 kernel. You either have a stock box, or a vanilla kernel box. Sorry.

And I don't know how you can change the fs type on the rootfs without either a) entering EM mode, or b) connecting the HDD externally.

Detailed instructions are now on the wiki


Top
   
PostPosted: Thu Jan 08, 2009 10:18 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
Thanks for the useful hints... Changing rootfs type is not an issue because I have experience on completely repartition the hard disk in EM-Mode, really no need to connect it externatlly. However, to mount the existing rootfs, XFS must be included in the new build, have you enable XFS in your build at the very beginning? Otherwise, it would not able to mount sda2...

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
PostPosted: Thu Jan 08, 2009 11:37 am 
Offline
Newbie

Joined: Sat Jan 03, 2009 11:47 pm
Posts: 26
XFS was enabled (You should be able to see it in the .config file I uploaded). I do suspect that it was having problems from the off, but having got a working box, I'm loathe to see if the old stock rootfs works now that the filesystems are ext3 (I know... I'm just not hardcore!)


Top
   
PostPosted: Thu Jan 08, 2009 11:45 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
Yes, just checked that from your .config. Seems not much special from mine apart from the sound stuff... so am I correct that different between the utilities in the old stock root and you current one is OABI vs EABI?

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
PostPosted: Thu Jan 08, 2009 12:01 pm 
Offline
Newbie

Joined: Sat Jan 03, 2009 11:47 pm
Posts: 26
Yup. I don't know how much you've read up on the difference, but basically (amongst other things) it changes the byte alignment of values passed in function calls. Most applications don't mind too much and the OABI compatibility layer deals with them. Some apps have more problems. The Alsa ones are an example of this. I presume that there may be others. The stock rootfs is from etch and is an "arm" build (Meaning conventionally OABI). The lenny one is "armel" which is the EABI. There were certainly applications in the etch one which appeared to be compiled for EABI, but I'm not certain. What I am sure of is that the 2.6.28 kernel + Lenny rootfs works (For me... normal caveats apply). I couldn't get into EM mode, hence my use of an adapter.

I would say that the buffalo case is exceptionally well-designed. I've disassembled a WRT54GL router which basically just involves pulling hard until it explodes into two pieces. The Buffalo case was designed to work with, useable.


Top
   
PostPosted: Thu Jan 08, 2009 4:18 pm 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
JonSenior wrote:
The stock rootfs is from etch and is an "arm" build (Meaning conventionally OABI)
What about the stock kernel, also "arm" build?
JonSenior wrote:
I couldn't get into EM mode, hence my use of an adapter.
I am "glad" to inform you that I also need the cable now... You are right, cannot get it enter EM mode with the interrupt boot process 3 times method. No tftp trigger either because the hard disk, especially ext3 /boot partition is actually accessible. :cry:

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
PostPosted: Thu Jan 08, 2009 7:10 pm 
Offline
Newbie

Joined: Sat Jan 03, 2009 11:47 pm
Posts: 26
Quote:
What about the stock kernel, also "arm" build?

I think it's armel, but heavily patched. I'm not certain about this though. It all got a little confusing.
Quote:
I am "glad" to inform you that I also need the cable now... You are right, cannot get it enter EM mode with the interrupt boot process 3 times method. No tftp trigger either because the hard disk, especially ext3 /boot partition is actually accessible.

Sorry. :roll: If you can't easily find that cable, you might be able to use a SATA external box and pilfer the connection, but the cable will definitely allow access without complete disassembly.


Top
   
PostPosted: Fri Jan 09, 2009 12:58 am 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
JonSenior wrote:
I think it's armel, but heavily patched. I'm not certain about this though. It all got a little confusing.
Yes, I would expect it's armel too because Buffalo seems use the same Cross Toolchain as what we are using...but that cannot explain why the stock rootfs not works on our custom build. Again, it might be heavily patched as you said...
JonSenior wrote:
you might be able to use a SATA external box and pilfer the connection, but the cable will definitely allow access without complete disassembly.
I think difficult to find such a cable here, I would simply go for an external case and a new drive for the backup. Switch over the already half full 250GB from XFS to JFS needed that anyways but I am still after a working kernel :cry:

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
PostPosted: Fri Jan 09, 2009 10:23 am 
Offline
Regular Member

Joined: Mon Oct 15, 2007 5:21 am
Posts: 144
If by "stock" root fs you mean the original one from Buffalo, its also armel (eabi), I believe.

The only oabi (debian-arm) rootfs is the Freelink v2 one. The cross-compiled eabi kernels
work with this because they have support for legacy oabi binaries.


Top
   
PostPosted: Fri Jan 09, 2009 7:36 pm 
Offline
Newbie

Joined: Thu Apr 10, 2008 5:39 pm
Posts: 73
Location: HK
Thanks for the calification.

Another point I can think of is that since the vanilla kernel doesn't include any MICON driver in the kernel, I would expect the stock miconmon or miconapl will broke and cause the automatically reboot or unable to recognize a boot complete status kind of things...

@JonSenior, my box finally back alive after connecting the hard disk with an external hard disk case to the PC running ubuntu and recover the old kernel...

_________________
LinkStation Live V2, Stock Firmware: 1.20-0.76 Japan w/EXT3 root-fs & JFS Data Partitions


Top
   
PostPosted: Fri Jan 09, 2009 8:21 pm 
Offline
Site Admin
User avatar

Joined: Tue Jul 12, 2005 11:26 am
Posts: 3701
Location: JAPAN
Its a mixture of OABI and EABI, enhanced libraries were used. Any movement to later kernels will mean that you will need to use micro_evtd to handle the MICON. This can be obtained from Debian testing branch or from this site.

_________________
LS used as PVR and streaming source


Top
   
PostPosted: Sat Jan 10, 2009 2:41 pm 
Offline
Newbie

Joined: Sat Jan 03, 2009 11:47 pm
Posts: 26
@sluk: Congratulations. It's actually pretty painless, once you get past the "oh my god, I'm taking it all apart" moment.

@lb_worm: Thanks again for your clarifications here. I would very much like to put together a page on the wiki which details the boot procedure for the Linkstations (As in, from the point at which you press the power button, which kernels / images are running and when control is handed over, what EM "actually" is (in software) and where it is (in the hardware), etc). Sadly I think that a lot of it is currently beyond my understanding. If there is already such a page that I've not found, I'd be interested to see it. If not, and I start one, would you take a few minutes to add what you know you to it?


Top
   
PostPosted: Sat Jan 10, 2009 6:02 pm 
Offline
Site Admin
User avatar

Joined: Tue Jul 12, 2005 11:26 am
Posts: 3701
Location: JAPAN
I will take a look at the wiki. I am sure that something like that already exists but may be spread over a number of topics. Its very straightforward and would be easy to detail.

_________________
LS used as PVR and streaming source


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 283 posts ]  Go to page Previous 115 16 17 18 19 Next

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited