On Tue, 07 Jun 2016 22:57:38 +0200, pozz wrote:
> Il 07/06/2016 20:25, Tim Wescott ha scritto:
>> On Tue, 07 Jun 2016 21:15:13 +1000, Clifford Heath wrote:
>>
>>> On 07/06/16 20:49, pozz wrote:
>>>> I will use one MCU with integrated USB OTG peripheral for two
>>>> purposes:
>>>>
>>>> - bootloader for firmware upgrade from USB pendrive - USB connection
>>>> to an Android smartphone during application
>>>>
>>>> As you know, USB Host stack is a complex piece of code that has a
>>>> high Flash size.
>>>> In my scenario, I need two different USB Host: one for bootloader and
>>>> one for application.
>>>>
>>>> Is there a possibility to share the USB Host stack between bootloader
>>>> and application in some way?
>>>>
>>>> Most probably, I'll use a Cortex-Mx MCU with gcc toolchain.
>>>
>>> Overlay linkers used to do this kind of thing, but really the right
>>> answer now is to create a jump table or a C++ object that implements a
>>> virtual interface, and expose it from the bootloader. Then in the
>>> application code all you need is a single pointer. Essentially it
>>> becomes your USB Host BIOS.
>>>
>>> You just need to ensure that any and all library code that gets
>>> dragged in is appropriate to both environments, for example, any
>>> memory that gets allocated in the bootloader gets freed there too, not
>>> by a free() in the app code.
>>>
>>> Clifford Heath.
>>
>> What everyone has said so far, plus:
>>
>> I'm going to go ahead and call it a BIOS here, because that's basically
>> what you're doing.
>>
>> Whatever you do you need to make sure to make the API between BIOS and
>> application code as consistent as possible. So -- a jump table, or a
>> single address that gets called with parameters, or possibly a
>> guaranteed-
>> unused interrupt that you hijack to branch to the BIOS.
>>
>> What you absolutely positively don't want to do is to just link the
>> boot code, then link the application code against the boot code's
>> 'native' addresses -- that will pretty much guarantee that each
>> application version will be firmly tied to a boot code version. You
>> want to have a system that maintains interoperability between as wide a
>> range of boot and applications versions. The less interoperability
>> there is, the bigger the configuration nightmare gets.
>>
> Il 07/06/2016 20:25, Tim Wescott ha scritto:
> > On Tue, 07 Jun 2016 21:15:13 +1000, Clifford Heath wrote:
> >
> >> On 07/06/16 20:49, pozz wrote:
> >>> I will use one MCU with integrated USB OTG peripheral for two
> >>> purposes:
> >>>
> >>> - bootloader for firmware upgrade from USB pendrive - USB
> >>> connection to an Android smartphone during application
> >>>
> >>> As you know, USB Host stack is a complex piece of code that has a
> >>> high Flash size.
> >>> In my scenario, I need two different USB Host: one for bootloader
> >>> and one for application.
> >>>
> >>> Is there a possibility to share the USB Host stack between
> >>> bootloader and application in some way?
> >>>
> >>> Most probably, I'll use a Cortex-Mx MCU with gcc toolchain.
> >>
> >> Overlay linkers used to do this kind of thing, but really the right
> >> answer now is to create a jump table or a C++ object that implements
> >> a virtual interface, and expose it from the bootloader. Then in the
> >> application code all you need is a single pointer. Essentially it
> >> becomes your USB Host BIOS.
> >>
> >> You just need to ensure that any and all library code that gets
> >> dragged in is appropriate to both environments, for example, any
> >> memory that gets allocated in the bootloader gets freed there too,
> >> not by a free() in the app code.
> >>
> >> Clifford Heath.
> >
> > What everyone has said so far, plus:
> >
> > I'm going to go ahead and call it a BIOS here, because that's
> > basically what you're doing.
> >
> > Whatever you do you need to make sure to make the API between BIOS
> > and application code as consistent as possible. So -- a jump table,
> > or a single address that gets called with parameters, or possibly a
> guaranteed-
> > unused interrupt that you hijack to branch to the BIOS.
> >
> > What you absolutely positively don't want to do is to just link the
> > boot code, then link the application code against the boot code's
> > 'native' addresses -- that will pretty much guarantee that each
> > application version will be firmly tied to a boot code version. You
> > want to have a system that maintains interoperability between as wide
> > a range of boot and applications versions. The less interoperability
> > there is, the bigger the configuration nightmare gets.
> >
> >
> Thank for your suggestions and advices. I understand perfectly what you
> are saying, but it's very difficult for me to really implement them in C
> and linker script.
Then either your tools or you need upgrading. Sorry if that's too blunt
-- but there's no softer way to put it.
On the bright side, the self-upgrade should be fun.
> It should be nice if there is some example, even about a totally
> different application, on the net that shows how to achieve what I'd
> like to do: sharing a set of functions (USB Host stack) between
> bootloader and application.
Locate a function or a jump vector at some fixed point in the boot code,
in a way that it will never, ever change. Then use an ioctl-like call to
that one spot from the app code. Make sure that the boot code has
adequate RAM.
This WILL require dinking with the linker script, or with the project
parameters if you use an IDE -- and if you use an IDE, you're almost
guaranteed that the protection will be broken with some future upgrade.
> Nowadays silicon manufacturers (NXP, Freescale, Microchip, Atmel, ...)
> publish a lot of example code for their evaluation boards, maybe one of
> those example shows what I'm trying to do.
In general the example code that I see is written by applications
engineers who are both fresh out of school and borderline incompetent.
They serve to demonstrate how bits of hardware work, but they usually do
so in the stupidest possible manner, which is usually also a manner that
makes it impossible to incorporate them into reasonably-written code.
Not that I'm, like, biased or anything, but I would not expect the
authors of the crap that I see to even be able to do what's necessary,
much less express it in an understandable manner.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I'm looking for work -- see my website!