Re: [linuxsh-dev] Today's addition

[<pi...@li...>]

Hello Niibe,

NIIBE Yutaka wrote:

> Hello Pierre!
>
> Thanks for your feedback.
>
> (1) RAMDISK issue
>
> I'll try that.  Thanks.
>
> (2) Initialization of SCI
>
> I think that this issue is resolved in current kernel (2.3.99-pre6 and
> later).  If not, please let us know.

I was working on pre5 but I'll upgrade and give it a try.

> (3) Peripheral clock
>
>  > Ideally, I think it'd be good to have an option in the .config to
>  > set the bus clock speed and have several tables defined and
>  > selected with #ifdefs.
>
> Yes, that'd be a solution.  Alternatively, we could use the value
> measured with RTC.  I'm thinking exporting the variable
> sh_periheral_clock and sh_module_clock from time.c.  I know that
> current code of time.c is not correct for all the cases, but it works
> at least for me.

I have to carry my modifications to the kernel to pre6 then I'll make
entries in the SH defconfigs. It'll be a solution until something nicer
is done, but I don't think it's too critical.

>  > I don't know if any of the above will help anyone but I thought I
>  > might share my findings.
>
> Surely, it helps much.  Thank you.
>
>  > Now for the plea for help :-) :
>
> Yes.  Welcome to the development team!!
>
>  > I assume everybody on the list has userland programs compiled
>  > dynamically and running good on their boards. For some reason, I
>  > can run programs that have been compiled statically against glibc
>  > just fine, but I can't run dynamically linked programs because
>  > ld.so segfaults (I use Kaz' latest patch for glibc). What happens
>  > is that ld.so starts, and eventually the function
>  > elf_machine_rela() (in sysdeps/sh/sh3/dl-machine.h) is called
>  > during the initial relocation from _dl_start() and the segfault
>  > occurs when the code tries (I think) to poke a fixed-up address in
>  > the code section (which is read-only) instead of the GOT (which is
>  > read-write).
>
> Your description is correct.  I guess that the target label to be
> resolved is the one of libgcc.a, isn't it?  Here is the story.
>

--8<--8<--SNIP-SNIP--8<--8<--

> Please let me know how this works (or not) for you, if you will try.

Wow, now that's indepth knowledge :)
I will certainly try and let you know my results.

Thank you very much,
Take care

---
Pierre-Philippe Coupard <pi...@li...>
Software Engineer, Lineo, Inc.
801-426-5001 x 208
---