It just seems to freeze at loading and even though I specified a load address it just goes with 0x0. Any ideas here?
=> setenv serverip 10.0.0.110
=> tftpboot $loadaddr kernel.bin
Using GbE#0 device
TFTP from server 10.0.0.110; our IP address is 10.0.0.7
Filename 'kernel.bin'.
Load address: 0x0
Loading: ##################
if you're going to do a TFTP boot, you probably need an all in one image, like an initramfs.
the kernel.bin is just the kernel part, it's no good without the root FS.
This is technically a x86 target but it is custom, for embedded devices, not like normal PC x86 with a BIOS.
OpenWrt had a target for this CPU in the past
https://archive.openwrt.org/backfire/10.03.1/x86_ep80579/
but it was unmaintained for many years and has been removed many releases ago https://github.com/openwrt/openwrt/search?q=ep80579&type=commits
Your best bet is to look at the old code and see if you can port it to modern OpenWrt.
This is a tough job even for a developer. It's probably better if you just let it go and find another device.
Thank you so much I thought I was going crazy, I knew it was completely different from any x86 hardware I had touched before. For now I am not to concerned about getting that latest version of openwrt on this because it will be running behind the firewall of my fileserver, I just want something that will allow me to setup a ZFS pool and hook it up to my main fileserver for dumping files since I have alot of old HDDs, It was supposed to be a little side project since the original firmware is terrible. If I were to just put that old version of openwrt on what would I have to do. After researching it seems I have to make a uImage because uboot only accepts this image type, is this true otherwise is there a tutorial out there I can follow, I keep getting cryptic answers from people lol I don't expect anyone to do it for me but Its hard when I have never done this before.
Many thanks for the help.
Forget it, the efforts and/ or security issues aside - zfs with 256 MB RAM...
Would RAID be better? That's what the original OS uses, I'm only setting up a 4tb pool not anything that big plus its mirrored no redundancy, the only thing I noticed was after copying say 100gb it would go from 100mb/s start then at about 20gb it would go down to 50mb/s and then down to 10mb/s until the 100gb was done. I don't mind as it would just be an archive for crap I don't want on my good file server running proper hardware/a secondary backup. Before I was using it as a dump for a nextcloud instance so I could share files to the internet that diddnt matter, eg games for friends.
There is no ZFS package for OpenWrt. So much for "a little side project" eh?
convert the vmlinuz file into a uimage (google this)
try loading it with tftp and see if it's at least starting up the kernel and not stopping just after loading.
find out your onboard flash chip specifications to see if it's using 64k blocks or 128k blocks
Find the partition list of the onboard flash (should be in uboot's "printenv", you can also see something in the boot log in the OP)
7 cmdlinepart partitions found on MTD device nand0
Using command line partition definition
Creating 7 MTD partitions on "nand0":
0x000000000000-0x000000200000 : "safe-k"
0x000000200000-0x000000a00000 : "safe-r"
0x000000a00000-0x000000c00000 : "kernel"
0x000000c00000-0x000001400000 : "rootfs"
0x000001400000-0x000002400000 : "usr"
0x000002400000-0x000002600000 : "data"
0x000002600000-0x000007fc0000 : "app"
since you don't want to touch sources, you probably need to edit the bootcommand in uboot to have a rootfs= variable that points to the /dev/mtd2 or something. Hoping that the pre-compiled kernel is actually receiving the partition table fro the uboot.
If it is not, you need to find where in the source code the partition table is defined, and then edit it to be correct for this device. Yes partition table in embedded devices is usually hard-coded in the kernel, this requires recompile, especially in old stuff like that that is not using dtb (which can be at least compiled separately and bundled with the kernel later).
Then use tftp to send to uboot the root-jffs2-xxxx file with the right block size and write it to the right partition, also send the uimage and write it to kernel partition.
The mere explanation of the steps to follow requires a lot of time and skill. What I told you above may or may not work for you and it's still very generic. You are not installing Ubuntu in a old PC where everything is following standards and the sequence of steps is defined and easy to follow.
You are reverse-engineering how a specific embedded device is built and trying to take over with a different firmware (that also has not been maintained for over 10 years). A lot of what you must do requires trial and error to find out the right combination, and also understanding of how uboot and devices work to guess what COULD work in the first place.
Thanks man ill give it ago, yeh haha not that small after all, I am used to everything just working like that to be honest, I didn't think about it that way. I really do appreciate the help im just way to fast with things, this cant be rushed I see now. Ill make it my goal to get openwrt running on this annoying thing and get back to you with updates if you want.
A 2 MB kernel partition is also a recipe for plenty of grey hairs (especially on x86).
I diddnt even look at that 
. I saw this while doing a little bit of research https://github.com/alexeicolin/javelin but I dont think hes using the same nas as me and has powerpc version of my nas. It would be nice to boot from a usb and not worry about openwrt.
Just curios, maybe this is not the place to ask but how did you start out learning things like this, did you go to uni, was it self taught or something else. I'm still in high school and they only introduced digital tech 3 years ago and it just goes over basic programing nothing more, its a shame most schools don't teach or introduce electronics and embedded devices like this, its all around us everyday. I think at one point they did have raspberry pi's but they just sat there or got stolen.
I don't think school or uni can go so much in depth of this topic, in any topic really. They always stay very generic. This is something you learn at work, in your free time or with videos and books and google.
There is some useful information to start in OpenWrt's techref section of the wiki https://openwrt.org/docs/techref/start but then you will have to google around on your own to find articles and blogs and documentation if you want to go deeper.
The way I learned (I'm not a real programmer/developer or hacker but I know the basics to add a device, I added some devices to OpenWrt) is trying to integrate support of some kirkwood-based devices (Zyxel NSA310 and NSA325, also Pogoplugv4) from someone else's work, on Jeff Doozan's forum https://forum.doozan.com/list.php?2 and OpenWrt already had some kirkwood devices supported.
So my task was more like study, copy and adapt something that was already more or less working and up-to-date in Debian. This is a strong point of open source. You can always look at someone else's work and learn from it.
You can see here some of the commits I made to add support for the Zyxel NSA325 https://github.com/openwrt/openwrt/search?q=kirkwood+nsa325&type=commits (most of the code in uboot commits is copied from the other project)
And I also had to read documentation especially for uboot bootloader, to learn how it works. http://www.denx.de/wiki/U-Boot
In general yes your approach is good, but you should try with something easier first, something where you can copy and learn (and ask) from someone else that knows the device well already. Your current device is probably a lost cause. With embedded devices it's common to encounter such "dead end" devices that are either too old, unknown or unsupported by modern Linux, so you need to know when it's probably better to just let go. It is hard enough when everything is good and supported.
Imho you can try with one of the devices that are supported by the custom Debian from the forum I linked above.
boards like raspberry pi are good to learn programming, how to program small embedded devices to make them do actions.
But it provides you a pre-built PC-like system with many GUI tools that automate everything so you don't need to know or learn bootloader, flash partitions and so on. You don't know how an embedded device is built.
A very interesting NAS architecture, looking at the stock bootlog you should expect a debian kernel, converted to a uImage, to be able to boot from a sata drive or tftp.
There may be some unsupported devices though - doesn't look like this is a common target. As boba suggests, first step is to boot the kernel and see what works.
To get a full OS operating I'd suggest the easiest path is to ignore the NAND flash and run straight Debian from one of the hard drives.
As this is x86 (mostly) you can install debian onto a drive in another machine, create the uImage and uInitrd, install the drive into the NAS and then use fsload to load the images in uBoot.
Example commands for creating uImage / uInitrd;
mkimage -A x86 -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.11.0-37 -d vmlinuz-5.11.0-37-generic uImage
mkimage -A x86 -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initrd.img-5.11.0-37-generic -d initrd.img-5.11.0-37-generic uInitrd
So I kind of threw myself in the deep end, It sort of seemed that way lol. This is really helpful, I have no connections with anyone who does this stuff, so its good to hear something like this. In regards to the gui tools, I want to wean myself off them, I want to properly understand the bare bones versions. Its like moving from windows to Linux I feel, It just needs the effort put in to learn. I see people using qemu to play around with u-boot, maybe ill play around with it that way before trying on real hardware. Ill give Debian ago, I diddnt see this before but apparently the nas has its own proprietary raid controller, maybe this will be a big issue for support. Thanks again for the reply.
Ill give this a try, do you think the proprietary raid controller will be an issue for support?
https://scratchpad.fandom.com/wiki/NS4600#CPU:_Intel_EP80579
This guy got Debian going on his ppc version of my nas would it be a similar process?
Thanks for the reply
I doubt you can run a "normal" x86 linux kernel from a distribution like debian as the minimal boot environment with u-boot doesn't provide acpi tables, which are the common way on x86 systems to detect the hardware and configure the drivers by the kernel.
So you have to use something like device trees or the ancient mach files to configure the drivers...
Hi,
I can't imagine the raid controller being an issue, linux has kernel modules for just about every controller ever created.
For the javelin instructions - you won't need to do anything this complex. Any i686 / i386 Debian root filesystem will be sufficient. Just install Debian i686 onto a usb drive or hard disk and that will be fine as a rootfs.
First step is to try booting a kernel and seeing if it bombs out. As Juppin says - x86 with uboot is pretty unique, the kernel may freak out - or it may boot with minimal hardware support. Can only try it and see.
just got my 4600 misfunctional because of faulty hdd and couple of hard reboots leads to unusable state so will be glad to participate in any kind of testing.
Ill give this ago after my end of years, this seems like a better way to do it instead of writing to NAND.
Thanks for the reply
Sad to hear that, ill try get something running after my end of years. Ill make sure to update you unless you figure something out before me.