lacie 5 big network v.1 please support for fvdw

[totorweb]

the telnet server is not responding.

I go to bed too ;)

[fvdw]

ok thats then for tomorrow

[taetae]

very good ;-)

If you need are here

[fvdw]

sorry to keep you waiting need to configure an optimal medium size busybox version static compiled with uclib, sounds easy

[taetae]

do not worry I understand that is not easy to take the time you need I connect again Monday because now they are offline and then leave again for work on Thursday! good job we'll see you Monday

[fvdw]

ok here it is, its smaller then 2 MB and the smaller initramfs is tested on a nwsp2 were the telenet client come up just fine

!	PS be aware that this intramfs is minimal, we need to upload a program to update the dev nodess for the HDD inside !! if they are wrong mounting the HDD may gave unwanted results.

Lets first test this standalone kernel. If it works then we will upload a program to update the dev nodes. We can check then if something has cganged in the dev node definition and if so adapt the default setting accordingly and update the standalone kernel initram filesystem

--edit 27 okt 2013
file removed, the kernel works but a new one (#30) is posted with corrected dev nodes.
go here viewtopic.php?f=4&t=1440&p=11486#p11492

[fvdw]

@mijzelf

still try to find out why isp1 and 2big1 can boot larger kernels while they also seem to load the kernel at 0x400000, but they can load a 3MB standalone kernel without a problem so it seem u-boot is not present at location 0x200000 like on 5big1

I tried to figure out were u-boot is on these boards but I can not find a u-boot source code of lacie for these boards. But I found one where the edmin_v2 is incorporated. That board of the isp1 and 2big1 is almost same if I am informed correctly
This u-boot version does not set a TEXT_BASE value (address in ram where u-boot is loaded as far as I understood) in the config.mk file of the edmini_v2
Instead they set this

Code: Select all

# TEXT_BASE must equal the intended FLASH location of u-boot.
CONFIG_SYS_TEXT_BASE = 0xfff90000

If you convert this hex number to decimal then you get a number that is much bigger than the RAM size of theses boards, so it can not be the address where it is loaded in RAM. But what does is the real meaning then ?
I googled a while on it but can find a clear answer what this number means, some mention it is the same as TEXT_BASE
But that number is larger then the physical RAM size in bytes.
So I guess u-boot uses virtual memory addresses. Then the max is 0xffffffff and it is mapped to physical memory by the kernel using paging and other complicated stuff.

--edit I checked on the isp1 and indeed u-boot is at (virtual) address 0xfff90000 so near the end of the RAM I suppose. Although I have no idea were it is really stored in physical ram which is only 64 MB, while virtual is 4 GB).

Anyhow no problems with a somewhat bigger kernel on the edmini_v2, isp1 and 2big1 as u-boot is not in the way :-D

(maybe it are stupid question but I try to learn and understand)

[fvdw]

@toterweb and tatae

can you test kernel 29 standalone ?

[totorweb]

Hi,

yeah i will test it now :)

[totorweb]

telnet is ok, root login ok. :)