Strange buildsystem behaviour

Strange buildsystem behaviour

[Lars Poeschel]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

Hello!

I am currently working on flash support for fr30, skmb91302 platform.
I added some code to platform.S file. I want to build a redboot image  
now and the following happens:
platform.S gets assembled to hal_fr30_skmb91302_platform.o and then  
added to libtarget.a correctly.
I can verify that the contents is there and correct with objdump.
Then redboot gets build, but the image (redboot.elf) does not contain  
my new code! The Linker seems to throw it away.
But when I copy the code from platform.S and paste it as it is without  
modification into variant.S(the .sections are the same), at first the  
same happens. The code gets assembled to hal_fr30_mb91301_variant.o  
and added to libtarget.a. But then redboot builds and the resulting  
image contains the code!
The linker script I use has no special rule for platform or variant  
files.
Does anybody have a hint for me ? How can I get the code linked when  
it is in platform.S ?

Thanks,
Lars


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Strange buildsystem behaviour

[Andrew Lunn]

> Does anybody have a hint for me ? How can I get the code linked when it 
> is in platform.S ?

The dependancy rules don't always work for some special files, eg
vectors.S. However, if the object file is getting into libtarget.a, it
should all work. The only exception would be if nothing actually uses
symbols you added, then the linker is expected not to link your
code....

Is this really reproducible? If you rm -fr your work tree and build
everything from clean, can you reproduce the problem?

           Andrew

Re: Strange buildsystem behaviour

[Lars Poeschel]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

>> Does anybody have a hint for me ? How can I get the code linked  
>> when it
>> is in platform.S ?
>
> The dependancy rules don't always work for some special files, eg
> vectors.S. However, if the object file is getting into libtarget.a, it
> should all work. The only exception would be if nothing actually uses
> symbols you added, then the linker is expected not to link your
> code....

I read about this and added a KEEP() around the regarding input  
sections, but it should not matter in this case, because for the  
variant.S file it works.

> Is this really reproducible? If you rm -fr your work tree and build
> everything from clean, can you reproduce the problem?

Yes, I can reproduce it. Just now it did 2 tests:

rm -rf *
ecosconfig new skmb91302 redboot
ecosconfig tree
make

Code is in when it is in variant.S, after that the same procedure with  
the code in platform.S and the code is not there.

Lars

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Strange buildsystem behaviour

[Andrew Lunn]

> I read about this and added a KEEP() around the regarding input  
> sections, but it should not matter in this case, because for the  
> variant.S file it works.

Im not sure this is true. I guess the KEEP() will only help if the
object file is loaded. If no symbols in the file are referenced, it
never loads the file and so never knows it needs to keep anything.

The real solution here is the reference one of your symbols which must
be in the image, or move it into libextras.a, which the linker will
never discard symbols from.

      Andrew

Re: Strange buildsystem behaviour

[Lars Poeschel]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]


Am 18.06.2008 um 12:22 schrieb Andrew Lunn:

>> I read about this and added a KEEP() around the regarding input
>> sections, but it should not matter in this case, because for the
>> variant.S file it works.
>
> Im not sure this is true. I guess the KEEP() will only help if the
> object file is loaded. If no symbols in the file are referenced, it
> never loads the file and so never knows it needs to keep anything.

YES!
Thanks Andrew this was the solution!
variant.S had some other symbol that was referenced but platform.S did  
not have this symbol. If I make a "dummy" reference to the new code in  
platform.S from somewhere else gets included.

Thanks again!

Lars


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Partition support for FAT file system

[Frank Pagliughi]

It appears that the FAT file system in eCos works if the "whole disk" is 
a single partition, meaning that the FAT Boot Sector is written into the 
MBR at sector zero. But if the disk uses a partition table in the MBR, 
then the code doesn't understand it, rejects the disk as non-FAT, and 
fails the mount. This happens even if the disk contains only a single 
partition.

I guess a quick enhancement would be for fatfs_mount() or fatfs_init() 
to check the partition table, see if there's at least one entry, and 
mount the first one it finds. If there are no partition entries, *then* 
check if the MBR is a valid FAT boot sector. This would make most disks 
(and compact flash cards) at least partially useful, rather than being 
rejected out right.

As a longer term enhancement, supporting multiple partitions would be 
nice, but ideas on how to resolve the devs/mtab idea of a disk to 
different partitions would be appreciated.

- Frank

Re: Partition support for FAT file system

[Nick Garnett]

Frank Pagliughi <fpagliughi@mindspring.com> writes:

> It appears that the FAT file system in eCos works if the "whole disk"
> is a single partition, meaning that the FAT Boot Sector is written
> into the MBR at sector zero. But if the disk uses a partition table in
> the MBR, then the code doesn't understand it, rejects the disk as
> non-FAT, and fails the mount. This happens even if the disk contains
> only a single partition.
> 
> I guess a quick enhancement would be for fatfs_mount() or fatfs_init()
> to check the partition table, see if there's at least one entry, and
> mount the first one it finds. If there are no partition entries,
> *then* check if the MBR is a valid FAT boot sector. This would make
> most disks (and compact flash cards) at least partially useful, rather
> than being rejected out right.
> 
> As a longer term enhancement, supporting multiple partitions would be
> nice, but ideas on how to resolve the devs/mtab idea of a disk to
> different partitions would be appreciated.


This is already handled in the io/disk package. You mount /dev/diskN/M
for partition M of disk N and /dev/diskN/0 for the whole disk. 

Partitioning is independent of filesystem type, so it must be done at
a lower level that the FATFS.

-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

Re: Partition support for FAT file system

[Frank Pagliughi]

Nick Garnett wrote:
> Frank Pagliughi <fpagliughi@mindspring.com> writes:
>   
>> As a longer term enhancement, supporting multiple partitions would be
>> nice, but ideas on how to resolve the devs/mtab idea of a disk to
>> different partitions would be appreciated.
>>     
>
>
> This is already handled in the io/disk package. You mount /dev/diskN/M
> for partition M of disk N and /dev/diskN/0 for the whole disk. 
>
> Partitioning is independent of filesystem type, so it must be done at
> a lower level that the FATFS.
>
>   
Ah, ok, thanks, Nick. I misunderstood that terminology in the IDE case, 
mistaking it as 'N' for the controller and 'M' for the disk on that 
controller. This makes sense.

So then it's the IDE driver that should scan the partition table on the 
physical disk and export separate mount points for each? Would that be 
the proper way to go?

Frank

Re: Partition support for FAT file system

[Nick Garnett]

Frank Pagliughi <fpagliughi@mindspring.com> writes:

> So then it's the IDE driver that should scan the partition table on
> the physical disk and export separate mount points for each? Would
> that be the proper way to go?

No, the generic disk layer already does all of this. It reads the MBR
from the disk, looks for a partition table and sets up its data
structures accordingly. 

Take a look in io/disk/current/src/disk.c, specifically the read_mbr()
and read_partition() functions. And the code in disk_lookup() which
selects the right partition.

In the same way that it shouldn't be done at too high a level,
partitioning shouldn't be done at too low a level either. Partitions
can exist on a wide variety of media, not just IDE disks.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

Re: Partition support for FAT file system

[Frank Pagliughi]

>>
>> This is already handled in the io/disk package. You mount /dev/diskN/M
>> for partition M of disk N and /dev/diskN/0 for the whole disk.
>> Partitioning is independent of filesystem type, so it must be done at
>> a lower level that the FATFS.
>>
>>   
> Ah, ok, thanks, Nick. I misunderstood that terminology in the IDE 
> case, mistaking it as 'N' for the controller and 'M' for the disk on 
> that controller. This makes sense.
>
> So then it's the IDE driver that should scan the partition table on 
> the physical disk and export separate mount points for each? Would 
> that be the proper way to go?
Nevermind. I found my mistake....

The name of the disk should end with a slash, like "/dev/disk0/", and 
then the lookup functionality in the disk library scans for partitions. 
I had left off the final slash and then cyg_io_lookup() was failing the 
exact match.

Thanks again for the help,
Frank

Re: Partition support for FAT file system

[Frank Pagliughi]

Nick Garnett wrote:
> Frank Pagliughi <fpagliughi@mindspring.com> writes:
>
>   
>> So then it's the IDE driver that should scan the partition table on
>> the physical disk and export separate mount points for each? Would
>> that be the proper way to go?
>>     
>
> No, the generic disk layer already does all of this. It reads the MBR
> from the disk, looks for a partition table and sets up its data
> structures accordingly. 
>
> Take a look in io/disk/current/src/disk.c, specifically the read_mbr()
> and read_partition() functions. And the code in disk_lookup() which
> selects the right partition.
>
> In the same way that it shouldn't be done at too high a level,
> partitioning shouldn't be done at too low a level either. Partitions
> can exist on a wide variety of media, not just IDE disks.
>
>
>   
By the way...  The main reason I had trouble with this, is because the 
one disk test application, fatfs1, doesn't work out of the box. The FAT 
test uses disks named like "/dev/disk0/"  whereas the IDE package 
defaults to names like "/dev/hda/". Is one naming convention preferred 
over the other? Should we change the default for one or the other?


- Frank