Dear All,
In continuation of
https://lore.kernel.org/linux-gpio/[email protected]/
Alexander please look at provided patch, the size goes from
```
text data bss dec hex filename
4491689 920748 92840 5505277 5400fd vmlinux
```
to with patch applied:
```
text data bss dec hex filename
4534485 927424 90304 5552213 54b855 vmlinux
```
If this is not acceptable to you, than it's perfectly fine, i'll
finish (actually only gpio left to rework to DT) and stash my rework
somewhere and can send link or patches to all interested.
But still if you have possibility to test clocks for video and I2S
it would be nice.
Otherwise i can proceed to multiarch and try to make it possible to
compile with or without multiarch support.
On Tue, May 25, 2021 at 10:36 AM Nikita Shubin
<[email protected]> wrote:
> text data bss dec hex filename
> 4491689 920748 92840 5505277 5400fd vmlinux
(...)
> text data bss dec hex filename
> 4534485 927424 90304 5552213 54b855 vmlinux
So IIUC that is 49472 bytes more text & data? ~48KB.
I think what really matters is the 2MB limit on compressed
kernel size, which I guess can be pushed a bit by
compressing the kernel with something violent like ZST but
ultimately what EP93xx might want to do is to do what
the other SoCs are doing for accommodating Android: move
out as many drivers as possible to be modules and
not compiled into the static kernel. Do we have candidates
for that? Are people normally using modules on EP93xx?
I am modernizing XScale IXP4xx and it doesn't suffer
from this as much: even the really ancient NSLU2 has
32MB of RAM.
Yours,
Linus Walleij
On Tue, 25 May 2021 12:19:27 +0200
Linus Walleij <[email protected]> wrote:
> move out as many drivers as possible to be modules and
> not compiled into the static kernel. Do we have candidates
> for that? Are people normally using modules on EP93xx?
AFAIK there is nothing left to convert. Everything is already done as
modules.
Hello Nikita!
On 25/05/2021 10:33, Nikita Shubin wrote:
> Alexander please look at provided patch, the size goes from
>
> ```
> text data bss dec hex filename
> 4491689 920748 92840 5505277 5400fd vmlinux
> ```
>
> to with patch applied:
>
> ```
> text data bss dec hex filename
> 4534485 927424 90304 5552213 54b855 vmlinux
> ```
>
> If this is not acceptable to you, than it's perfectly fine, i'll
> finish (actually only gpio left to rework to DT) and stash my rework
> somewhere and can send link or patches to all interested.
I don't think that 50k is a serios issue even for this HW.
And Arnd is right, we still have some potential hidden within
missing CONFIG_LD_DEAD_CODE_DATA_ELIMINATION support.
> But still if you have possibility to test clocks for video and I2S
> it would be nice.
I don't have video, but I2S and ADC, and earliest in 2 weeks.
Thank you for looking into this!
--
Alexander.
On Tue, 25 May 2021 21:39:27 +0200
Alexander Sverdlin <[email protected]> wrote:
Hello Alexander!
> Hello Nikita!
>
> On 25/05/2021 10:33, Nikita Shubin wrote:
> > Alexander please look at provided patch, the size goes from
> >
> > ```
> > text data bss dec hex filename
> > 4491689 920748 92840 5505277 5400fd vmlinux
> > ```
> >
> > to with patch applied:
> >
> > ```
> > text data bss dec hex filename
> > 4534485 927424 90304 5552213 54b855 vmlinux
> > ```
> >
> > If this is not acceptable to you, than it's perfectly fine, i'll
> > finish (actually only gpio left to rework to DT) and stash my
> > rework somewhere and can send link or patches to all interested.
>
> I don't think that 50k is a serios issue even for this HW.
> And Arnd is right, we still have some potential hidden within
> missing CONFIG_LD_DEAD_CODE_DATA_ELIMINATION support.
Then i will proceed into finalizing and submitting it.
>
> > But still if you have possibility to test clocks for video and I2S
> > it would be nice.
>
> I don't have video, but I2S and ADC, and earliest in 2 weeks.
Thank you very much!