can we include dosfs?

Ben Gras beng at shrike-systems.com
Mon Jun 20 15:42:42 UTC 2016


All,

An update..

  - I could add dosfs and fatfs and they built unmodified (nice work)
  - I could hook the SD i/o functions to dosfs from the shell without
modifications, also nice
  - Using it i was plagued by data abort exceptions. It seems GCC is
emiting unaligned accesses. I tried some workarounds
(un-__packed__-ing some structs and running -O1 instead of -O2 both
help) but adding -mno-unaligned-access was the simplest and works.

BTW this did cause me to import the RTEMS exception context saving &
printing code so now we can have nicer looking exception debugging :)

A question I have is how we should load ELF files. From some cursory
searching it seems there is an ELF loader which only works on a TFS
filesystem. Is that right? If so, I wonder which is less work - making
a TFS filesystem from the host or adapting that code to also be usable
on a FAT FS.

Thanks for any input!

Cheers,
Ben




On Mon, Jun 20, 2016 at 2:31 PM, Ben Gras <beng at shrike-systems.com> wrote:
> CCing list
>
> Great news, thank you. I'll get onto this so we can hopefully easily
> boot an rtems image on a fat filesystem on the am335x/bbb through
> uMon.
>
>
> On Mon, Jun 20, 2016 at 2:23 PM, Ed Sutter <ed.sutter at nokia.com> wrote:
>> Ben,
>> I'm replying to you directly because at the moment I can't write to
>> umon-devel
>> because my email address has changed to Nokia.  I already told Joel, so
>> hopefully
>> this will be resolved shortly...
>>
>> All of uMon that I wrote is Apache now; so there should be no problem just
>> taking
>> that.   I sent an earlier (bounced) email from my office as well...
>>
>>> if you decide you want either of the dosfs implementations they should
>>> be part of the tarball on my website.   The idea I ran with there was that
>>> they
>>> hooked to some other block-read/write interface to get to the actual
>>> device
>>> they were connected to.  That usually meant that there was a command in
>>> uMon that supported the raw block access to either SD, CF or NAND.
>>
>> Ed
>>
>>



More information about the umon-devel mailing list