can we include dosfs?
beng at shrike-systems.com
Mon Jun 20 15:42:42 UTC 2016
- 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!
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
> On Mon, Jun 20, 2016 at 2:23 PM, Ed Sutter <ed.sutter at nokia.com> wrote:
>> I'm replying to you directly because at the moment I can't write to
>> because my email address has changed to Nokia. I already told Joel, so
>> this will be resolved shortly...
>> All of uMon that I wrote is Apache now; so there should be no problem just
>> 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
>>> hooked to some other block-read/write interface to get to the actual
>>> 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.
More information about the umon-devel