Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Sun May 27, 2018 8:40 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 18 posts ]  Go to page Previous 1 2
Author Message
PostPosted: Thu Nov 01, 2012 6:24 am 
Offline
Newbie

Joined: Thu Nov 30, 2006 7:30 am
Posts: 30
DJWillis wrote:
My current plan (for ease) after some more reading and tinkering is to hack kexec support (well backporting a later 2.4 PPC patch) into the Buffalo kernel if that turns out to be viable.


What does that buy you that loader.o does not? And with loader.o, there is no risk to completely bricking (need JTAG) the box.

Also, for your method, the initrd would have to also contain additional filesystem code to to boot the USB as you mention below - it currently only has a few meg to spare and I'm not sure off the top of my head if additional filesystems are included. I suspect not.

Really, in my opinion, with your experience.... If you're going to flash the firmware, just go for the holy grail and replace kernel+initrd with uboot and then you can have uboot boot anything you want.

DJWillis wrote:
As for launching some other kernel of any description. My view was to have a script placed in the existing rootfs that will check for the presence of a USB stick with an initial FAT volume with some control files and if they are found kexec uboot off that FAT partition leaving you pretty much free to do whatever you want on the device. The normal idea would be then having that uboot then load a kernel off a 2nd EXT3 volume but it could actually be anything from just about anywhere ;).

If the stick is removed or there is something like a 'DISABLE' file on the USB FAT volume the script will will just skip over and load the normal 2.4 firmware as is.


This is less risky that flashing the kernel+initrd files. Since I don't have a JTAG setup, this is a scheme similar to what I was working on.

stock boot loader -> stock kernel + intird -> loader.o of some other kernel or uboot

You really only need one usb partition/filesystem that can hold uboot, kernel, initrd, scripts, everything.

The biggest problem that I saw was once you have gotten to the point you can run loader.o, you have mounted the filesystem and it basically dumps the kernel image in core and starts a new one. This caused a RAID rebuild for me. I guess the control files could probably check and unmount/disassemble the array first, but at least the rootfs will end up getting rebuilt each time this way.


Top
   
PostPosted: Thu Nov 01, 2012 9:11 pm 
Offline
Total Newbie

Joined: Sat Oct 27, 2012 9:04 pm
Posts: 3
entropy wrote:
DJWillis wrote:
My current plan (for ease) after some more reading and tinkering is to hack kexec support (well backporting a later 2.4 PPC patch) into the Buffalo kernel if that turns out to be viable.


What does that buy you that loader.o does not? And with loader.o, there is no risk to completely bricking (need JTAG) the box.


Other than the academic exercise of back porting kexec support it buys me nothing ;).

As it happens when I posted this I did not know about the existence of the loader.o/uloader.o kernel module exploit and as such talked about just reinventing the wheel :D.

No point doing any of that now but I would not mind a pointer to the definitive loader.o source for the TSP V1 as at the moment I have bits of source from the uloader.o from other PPC Buffalo devices.

entropy wrote:
This is less risky that flashing the kernel+initrd files. Since I don't have a JTAG setup, this is a scheme similar to what I was working on.

stock boot loader -> stock kernel + intird -> loader.o of some other kernel or uboot

You really only need one usb partition/filesystem that can hold uboot, kernel, initrd, scripts, everything.

The biggest problem that I saw was once you have gotten to the point you can run loader.o, you have mounted the filesystem and it basically dumps the kernel image in core and starts a new one. This caused a RAID rebuild for me. I guess the control files could probably check and unmount/disassemble the array first, but at least the rootfs will end up getting rebuilt each time this way.


I have seen similar problems to that with Linux soft MD RAID arrays when moving to and from 2.4 <> 2.6 in the past. Fully unmounting helped in those cases and there is no reason you can't force remount everything RO before you call out to loader.o.

I also see your point about one big partition with everything on but my reasoning to avoid that was because it ties you to using a filesystem on the 2.6 side that can be read from the 2.4 kernel (so stock 2.4 kernel/fs -> loader.o with safety wrapper ;) -> USB uboot would work).

By having the 1st volume on the USB as a FAT32 volume you have no problems mounting it in the 2.4 arena and just sucking the uboot from that. Once you have uboot running your good to go really and can load up anything uboot knows of and assuming I can get a recent uboot going (easier said than done right now) you have a pretty flexible starting point ;). Nothing then stopping you having a massive (in embedded terms) root file system on say an EXT3 or BTRFS volume with lots of interesting modules built for lots of interesting things.

To be totally honest it sounds like we both have broadly the same ideas.

I don't really want to tamper with the 2.4 kernel or flash much if at all possible so it ends up staying as a sort of safety net and also frees you up to use a USB RootFS on the 2.6/3 side that is as small or as large as you want based on your needs.

My own aim is to get the basics going and leave the box sat there with a small USB stick and have it load up a basic Angstrom (an OpenEmbedded based disto) setup with SSH, samba and webmin ;).

Not sure if I will ever get that far or just run out of steam but there is nothing fundamental that makes that goal unreasonable.

Any more info on recent kernel tress and the like would be great if you have them. I have just started with the latest 3.* stable as a base and latest uboot and have a massive set of various patches I have found scatted all over the 4 corners of the interwebs ;).


Top
   
PostPosted: Fri Nov 02, 2012 4:13 am 
Offline
Newbie

Joined: Thu Nov 30, 2006 7:30 am
Posts: 30
DJWillis wrote:
No point doing any of that now but I would not mind a pointer to the definitive loader.o source for the TSP V1 as at the moment I have bits of source from the uloader.o from other PPC Buffalo devices.


The example boot I did previously in the thread was using Andre's bootloader. I didn't compile it, I just used his binary:
http://hvkls.dyndns.org/downloads/docum ... oader.html

Loader.o sources can be found here, I assume these are the same:
http://downloads.buffalo.nas-central.or ... t/Sources/

DJWillis wrote:
Any more info on recent kernel tress and the like would be great if you have them. I have just started with the latest 3.* stable as a base and latest uboot and have a massive set of various patches I have found scatted all over the 4 corners of the interwebs ;).


This is probably the best success booting 2.6 I've seen: viewtopic.php?f=11&t=2935

There is some good notes on driver/watchdog issues, and the subversion repository still exists.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 18 posts ]  Go to page Previous 1 2

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 5 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