lacie 5 big network v.1 please support for fvdw

Re: lacie 5 big network v.1 please support for fvdw

Postby taetae » Wed Oct 23, 2013 10:12 pm

ok .... ;-)
taetae
Donator VIP
Donator VIP
 
Posts: 438
Joined: Mon Aug 26, 2013 9:02 am

Re: lacie 5 big network v.1 please support for fvdw

Postby Mijzelf » Thu Oct 24, 2013 7:19 am

fvdw wrote:I did not disable the clock interrupt
No, you didn't. U-boot does.

As I 'quoted' from the u-boot source, the boot process after verifying the checksum is:
  • Disable interrupts
  • Copy 'kernelsize' data from 0x0400000 to 0x08000
  • Print the second 'OK'
  • Execute code on 0x08000 (if the load address is the same as the entrypoint)
About the first thing the kernel does is setting the new interrupt vector table, and enabling the interrupts.
Mijzelf
 
Posts: 255
Joined: Wed Nov 21, 2012 9:12 am

Re: lacie 5 big network v.1 please support for fvdw

Postby fvdw » Thu Oct 24, 2013 1:06 pm

I see

I did not look at kernel address a lot yet. But in case the kernel is loaded ad address 0x400000 it means at byte 4194304 of the ram.
So we have max 4.2 MB of space there
But the data (how big is this ?) is copied to 0x8000 so effecitvely we have about 4.1 MB space for that before it overwrite itself
Should be enough for a kernel of 3 MB (unless it is uncompressed)

So what size may the kernel be then to fit

ps then loading it at 800000 shuld give more space...unless there is stored more in between 0 en the first 4.1 MB of the RAM
fvdw
Site Admin - expert
 
Posts: 13471
Joined: Tue Apr 12, 2011 2:30 pm
Location: Netherlands

Re: lacie 5 big network v.1 please support for fvdw

Postby Mijzelf » Thu Oct 24, 2013 6:13 pm

But in case the kernel is loaded ad address 0x400000 it means at byte 4194304 of the ram.
So we have max 4.2 MB of space there
? The uImage is loaded @0x0400000 and up. So when nothing is in it's way, you have 124MiB of space.
the data (how big is this ?)
uImage minus the header, which is 64 bytes.
But the data is copied to 0x8000 so effecitvely we have about 4.1 MB space for that before it overwrite itself
The kernel overwriting itself is no problem, I think. When the tail of the copy overwrites the head of the 'original', that head has already been copied.
then loading it at 800000 shuld give more space...unless there is stored more in between 0 en the first 4.1 MB of the RAM
At this stage we have u-boot, the u-boot environment, and some u-boot stack/heap. I guess it's SPI flash, so u-boot can't run from flash.
Further there is the uImage. That's it, I think. Maybe an interrupt vector table, but I don't know where that is. I thought the a part of u-boot was around 0x0800000, but it seems not to be there, as loading at 0x0400000 or 0x1000000 gave the same result. So *if* u-boot (or it's stack) is overwritten, it is somewhere in 0x08000 + kernelsize.
So what size may the kernel be then to fit
How big is the 'normal' kernel? If you add 0x08000 and round that up to a nice value (binary of course), that might be the maximal size (after subtrackting that 0x08000 again).
Mijzelf
 
Posts: 255
Joined: Wed Nov 21, 2012 9:12 am

Re: lacie 5 big network v.1 please support for fvdw

Postby fvdw » Thu Oct 24, 2013 7:57 pm

But in case the kernel is loaded ad address 0x400000 it means at byte 4194304 of the ram.
So we have max 4.2 MB of space there
? The uImage is loaded @0x0400000 and up. So when nothing is in it's way, you have 124MiB of space.

What I meant from start of ram to position were kernel is loaded we have 4.2 MB of space available between start of RAM and position were kernel is uploaded.

I thought the a part of u-boot was around 0x0800000, but it seems not to be there
...
So *if* u-boot (or it's stack) is overwritten, it is somewhere in 0x08000 + kernel size.

I think you mean between 0x8000 and 0x400000 ? then moving the kernel to that area could indeed overwrite u-boot if the the kernel is bigger then the normal one

How big is the 'normal' kernel?
that has a size of 1.8 MB
the problem is I need to add an initranfs with a static version of busybox that increase the size considerably. I think the only way to bring it to a size smaller then 2 MB is using a mini version of busybox with only basic commands in it.

I have doe sthe isp1 and 2big1 do not have an issue with the standalone kernel of 3 MB? Would lacie have made a difference in the position of loading u-boot in RAM :scratch The fact that other ub-boot versions load the kernel at 0x800000 points in that direction

anyhow I am going to try to make small standalone kernel of max 1.9 MB
fvdw
Site Admin - expert
 
Posts: 13471
Joined: Tue Apr 12, 2011 2:30 pm
Location: Netherlands

Re: lacie 5 big network v.1 please support for fvdw

Postby Mijzelf » Thu Oct 24, 2013 8:44 pm

You know that it's possible to put the initramfs in a separate uImage? That is generally called a uInitrd. In that case you can upload it somewhere 'in the ocean' above 16M, and put only the bare kernel at 0x08000.
Mijzelf
 
Posts: 255
Joined: Wed Nov 21, 2012 9:12 am

Re: lacie 5 big network v.1 please support for fvdw

Postby fvdw » Thu Oct 24, 2013 9:00 pm

Mijzelf wrote:You know that it's possible to put the initramfs in a separate uImage? That is generally called a uInitrd. In that case you can upload it somewhere 'in the ocean' above 16M, and put only the bare kernel at 0x08000.

No I didn't know that and thats a good tip thanks, learned again something :thumbup I will look at that

for tataue and totorweb, please try this kernel (of course tftpuplaod upload to 0x400000)

Hopefully this one boots, it is smaller then the normal kernel but is very much stripped down + mini busybox static
But it is only for testing f the kernel size is the problem
You do not have the required permissions to view the files attached to this post.
fvdw
Site Admin - expert
 
Posts: 13471
Joined: Tue Apr 12, 2011 2:30 pm
Location: Netherlands

Re: lacie 5 big network v.1 please support for fvdw

Postby fvdw » Thu Oct 24, 2013 10:16 pm

I think I may have found the reason why the standalone kernel doesn't run. On the 5big1 it seems u-boot is at a location were it is overwritten by the kernel when this kernel is too big.
It seems that some orion based boards load u-boot at 0x200000 (or at byte 2097152) while kirkwood based devices seems to use 0x600000 (or at byte 6291456)
That means when the kernel is moved to 0x8000 there is for the ones having u-boot at 0x200000 only space for a kernel of 2 MB while on the others 6 MB before you overwrite u-boot.
This also explains why the kirkwood based boards upload a kernel to address 0x800000 and not 0x400000 as they then would overwrite u-boot.

Last thing not explained yet, why can the 2big1 and isp1 (both orion boards) boot a standalone kernel bigger then 2 MB ? Thats then only possible if they have u-boot loaded at higher up in the memory then the 5big1 or they boot u-boot directly from flash
fvdw
Site Admin - expert
 
Posts: 13471
Joined: Tue Apr 12, 2011 2:30 pm
Location: Netherlands

Re: lacie 5 big network v.1 please support for fvdw

Postby totorweb » Thu Oct 24, 2013 10:24 pm

look at this ;)

Code: Select all
Marvell>> bootm 0x400000
bootm 0x400000
## Booting image at 00400000 ...
   Image Name:   Linux-2.6.39.4
   Created:      2013-10-24  20:50:11 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1815908 Bytes =  1.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Linux version 2.6.39.4 (root@fvdwsl-5big2.local) (gcc version 4.5.4 (GCC) ) #27
PREEMPT Thu Oct 24 21:49:48 GMT+1 2013
CPU: Feroceon [41069260] revision 0 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: LaCie 5Big1 Network
Clearing invalid memory bank 0KB@0x00000000
Clearing invalid memory bank 0KB@0x00000000
Clearing invalid memory bank 0KB@0x00000000
Ignoring unrecognised tag 0x00000000
Ignoring unrecognised tag 0x00000000
Ignoring unrecognised tag 0x00000000
Ignoring unrecognised tag 0x41000403
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyS0,115200 netconsole=6666@192.168.0.252/,6666@19
2.168.0.12/
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126388k/126388k available, 4684k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc8800000 - 0xfd800000   ( 848 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc0063000   ( 364 kB)
      .text : 0xc0063000 - 0xc034b000   (2976 kB)
      .data : 0xc034c000 - 0xc035f6e0   (  78 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptable hierarchical RCU implementation.
        RCU-based detection of stalled CPUs is disabled.
        Verbose stalled-CPUs detection is disabled.


Ping is ok, telnet ko.

Great job, things are moving on ;)
I have attached the full console output in case you need some informations.
You do not have the required permissions to view the files attached to this post.
Last edited by totorweb on Thu Oct 24, 2013 10:30 pm, edited 1 time in total.
totorweb
 
Posts: 46
Joined: Fri Oct 18, 2013 11:28 am

Re: lacie 5 big network v.1 please support for fvdw

Postby fvdw » Thu Oct 24, 2013 10:29 pm

:punk finally

is telnet server running and accessible or not ? (you wrote telnet "ko")

ps be aware that this kernel is heavily stripped and busybox as well. To get full command for basic linux commands we will need to upload some stuff. also the /dev nodes definition is not update automatically that might give problems with mounting disk. Then you think you mount for instance sda while in reality it could be sdc. (we had this on the 5big2). The program udevstart needs to be execute after boot to set the nodes correctly. But because of the stripping its not in the standalone kernel anymore
This will be important when you try to recover for instance a raid array so be careful and wait with that until we are sure that the dev nodes definition is ok
All this can be solved. But not tonight, need to go to bed. More in this theater tomorrow
fvdw
Site Admin - expert
 
Posts: 13471
Joined: Tue Apr 12, 2011 2:30 pm
Location: Netherlands

PreviousNext

Return to Lacie 5Big Network vs1

Who is online

Users browsing this forum: No registered users and 5 guests