* Strange buildsystem behaviour
@ 2008-06-18 9:36 Lars Poeschel
2008-06-18 9:53 ` Andrew Lunn
0 siblings, 1 reply; 11+ messages in thread
From: Lars Poeschel @ 2008-06-18 9:36 UTC (permalink / raw)
To: ecos-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Strange buildsystem behaviour
2008-06-18 9:36 Strange buildsystem behaviour Lars Poeschel
@ 2008-06-18 9:53 ` Andrew Lunn
2008-06-18 10:07 ` Lars Poeschel
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2008-06-18 9:53 UTC (permalink / raw)
To: Lars Poeschel; +Cc: ecos-devel
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Strange buildsystem behaviour
2008-06-18 9:53 ` Andrew Lunn
@ 2008-06-18 10:07 ` Lars Poeschel
2008-06-18 10:23 ` Andrew Lunn
0 siblings, 1 reply; 11+ messages in thread
From: Lars Poeschel @ 2008-06-18 10:07 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Strange buildsystem behaviour
2008-06-18 10:07 ` Lars Poeschel
@ 2008-06-18 10:23 ` Andrew Lunn
2008-06-18 10:58 ` Lars Poeschel
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2008-06-18 10:23 UTC (permalink / raw)
To: Lars Poeschel; +Cc: Andrew Lunn, ecos-devel
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Strange buildsystem behaviour
2008-06-18 10:23 ` Andrew Lunn
@ 2008-06-18 10:58 ` Lars Poeschel
2008-06-18 16:26 ` Partition support for FAT file system Frank Pagliughi
0 siblings, 1 reply; 11+ messages in thread
From: Lars Poeschel @ 2008-06-18 10:58 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Partition support for FAT file system
2008-06-18 10:58 ` Lars Poeschel
@ 2008-06-18 16:26 ` Frank Pagliughi
2008-06-18 16:44 ` Nick Garnett
0 siblings, 1 reply; 11+ messages in thread
From: Frank Pagliughi @ 2008-06-18 16:26 UTC (permalink / raw)
To: ecos-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Partition support for FAT file system
2008-06-18 16:26 ` Partition support for FAT file system Frank Pagliughi
@ 2008-06-18 16:44 ` Nick Garnett
2008-06-18 17:01 ` Frank Pagliughi
0 siblings, 1 reply; 11+ messages in thread
From: Nick Garnett @ 2008-06-18 16:44 UTC (permalink / raw)
To: Frank Pagliughi; +Cc: ecos-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Partition support for FAT file system
2008-06-18 16:44 ` Nick Garnett
@ 2008-06-18 17:01 ` Frank Pagliughi
2008-06-18 19:26 ` Nick Garnett
2008-06-18 19:28 ` Frank Pagliughi
0 siblings, 2 replies; 11+ messages in thread
From: Frank Pagliughi @ 2008-06-18 17:01 UTC (permalink / raw)
To: Nick Garnett; +Cc: ecos-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Partition support for FAT file system
2008-06-18 17:01 ` Frank Pagliughi
@ 2008-06-18 19:26 ` Nick Garnett
2008-06-20 13:56 ` Frank Pagliughi
2008-06-18 19:28 ` Frank Pagliughi
1 sibling, 1 reply; 11+ messages in thread
From: Nick Garnett @ 2008-06-18 19:26 UTC (permalink / raw)
To: Frank Pagliughi; +Cc: ecos-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Partition support for FAT file system
2008-06-18 19:26 ` Nick Garnett
@ 2008-06-20 13:56 ` Frank Pagliughi
0 siblings, 0 replies; 11+ messages in thread
From: Frank Pagliughi @ 2008-06-20 13:56 UTC (permalink / raw)
To: Nick Garnett; +Cc: ecos-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Partition support for FAT file system
2008-06-18 17:01 ` Frank Pagliughi
2008-06-18 19:26 ` Nick Garnett
@ 2008-06-18 19:28 ` Frank Pagliughi
1 sibling, 0 replies; 11+ messages in thread
From: Frank Pagliughi @ 2008-06-18 19:28 UTC (permalink / raw)
To: Frank Pagliughi; +Cc: Nick Garnett, ecos-devel
>>
>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-06-20 13:56 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-18 9:36 Strange buildsystem behaviour Lars Poeschel
2008-06-18 9:53 ` Andrew Lunn
2008-06-18 10:07 ` Lars Poeschel
2008-06-18 10:23 ` Andrew Lunn
2008-06-18 10:58 ` Lars Poeschel
2008-06-18 16:26 ` Partition support for FAT file system Frank Pagliughi
2008-06-18 16:44 ` Nick Garnett
2008-06-18 17:01 ` Frank Pagliughi
2008-06-18 19:26 ` Nick Garnett
2008-06-20 13:56 ` Frank Pagliughi
2008-06-18 19:28 ` Frank Pagliughi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).