All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] Linux openrisc init code...
Date: Mon, 6 Feb 2017 22:28:20 +0900	[thread overview]
Message-ID: <20170206132820.GE32144@lianli.shorne-pla.net> (raw)
In-Reply-To: <24B059156D2D4E54AAF93CA262AA7986@BAndViG>

Hi Andrey,

On Sun, Feb 05, 2017 at 01:02:19PM +0300, BAndViG wrote:
> My experience (on Atlys board).
> 
> About R0 initialization
> If somebody use NewLIB tool chain, the R0 is set to zero during run-time
> initialization for any program build with the tool chain.
> In particular I use U-Boot compiled with NewLIB tool chain, so R0 is already
> initialized.
> On the other hand if somebody want to launch Linux in another way, R0, of
> course, should be set to zero somewhere in Linux initialization routines.

Agreed, I have a patch to do this now.

> About Linux and U-Boot
> Currently I use quite old U-Boot and Linux versions. Both downloaded long
> time ago from openrisc.org when the site was operable. In particular, I also
> use Jonas' tree Linux sources.
> After Linux build I do two things:
> 1) Convert vmlinux (which is ELF originally) to bin.
> 2) Create U-Boot image with command:
> mkimage -n 'Linux for OpenRISC' -A or1k -O linux -T kernel -C none -a 0 -e
> 0x100 -d vmlinux.bin ~/tftpshare/vmlinux.ubi

Thanks, this is good to know.  I guess then you have uboot running on
your board with an ethernet connection ahd the image is pulled down over
ethernet during boot.

> However, I haven't tried this with latest Linux version. As far as I
> understand option "-e 0x100" passes to mkimage boot address and add
> information to U-boot image how the image should be placed in RAM. Does it
> mean that the approach doesn't work with linux-next?

I am not sure if Jonas had anything special.  But there have not been
any major changes so far in this aspect to the kernel.  The changes
going in are mostly cleanups and a few optimizations like memcpy and
memset.

If you want to try the next kernel is here:

  https://github.com/openrisc/linux/tree/for-next

Coming up will be bigger things like SMP and drivers.

Thanks for the info.

-Stafford

> WBR
> Andrey
> 
> 
> -----Исходное сообщение----- From: Stafford Horne
> Sent: Sunday, February 05, 2017 11:43 AM
> To: Jakob Viketoft
> Cc: Jonas Bonn ; openrisc at lists.librecores.org
> Subject: Re: [OpenRISC] Linux openrisc init code...
> 
> Hello Jakob,
> 
> On Sat, Feb 04, 2017 at 08:33:45PM +0000, Jakob Viketoft wrote:
> > Hello!
> > 
> > I've already left dealing with Linux on openrisc, but your recent posts
> > sparked a remembrance of couple of bug fixes I've made locally, I might
> > as well share and you can do with that info as you please. :)
> 
> I see, any comments or history lessons are appreciated.
> 
> > First off is the very initial code in arch/openrisc/head.S:
> > As I recall it, r0 isn't actually tied to zero explicitly and the
> > current init code fails in e.g. a simulator. I'd like to change the
> > CLEAR_GPR method to use l.movhi instead and also explicitly clear r0
> > before using that in any instruction.
> 
> I haven't seen this fail before, and I haven't seen a patch before.
> Nevertheless, you are right, the architecture doc clearly says:
> 
>  R0 should always hold a zero value. It is the responsibility of
>  software to initialize it. (This differs from architecture version 0
>  which commented on implementation and that it should never be used as a
>  destination register – this is no longer specified.)
> 
> I also had a look through the mor1kx code and I cant see any place that
> r0 is tied to ground, its just another address in the register file.
> 
> I will fix it. Thanks.
> 
> > The second one I can't find anymore in linux-next, whether it's been
> > removed completely or was only part of Jonas' tree I can't tell, but I
> > thought I'd share anyway. There was a rule to create a dtb-image
> > suitable for u-boot, but it gave the wrong jump-to address in the
> > kernel. Originally it says 0x100 which is reset and which will clear the
> > dtb argument given by u-boot. I corrected this to 0x400000 to be able to
> > do the handover between u-boot and the kernel using different dtb-images
> > based on the board.
> 
> I haven't seen any patches related to this either. While we are at it here
> is the start code from head.S:
> 
>  .org 0x2000
>        __HEAD
>        .global _start
>  _start:
>        /* save kernel parameters */
>        l.or    r25,r0,r3       /* pointer to fdt */
> 
>        /*
>         * ensure a deterministic start
>         */
> 
>        l.ori   r3,r0,0x1
>        l.mtspr r0,r3,SPR_SR
> 
>        CLEAR_GPR(r1)
>        CLEAR_GPR(r2)
>        CLEAR_GPR(r3)
> 
> 
> As you see above, we accept r3 as a pointer to the dtb image. It is not
> cleared.  But, I am not clear where or what you would correct to 0x400000.
> 
> Where was the rule to create the u-boot dtb-image? A build option? A
> code path?
> 
> I haven't really looked into using a bootloader for my own setup yet so
> I don't really know all of the details of how it would work.  Do you
> perhaps have some example of another cpu that has this setup?
> 
> -Stafford
> 
> > Best regards,
> > 
> >        /Jakob
> > 
> > 
> > Jakob Viketoft
> > Senior Engineer in RTL and embedded software
> > 
> > ÅAC Microtec AB
> > Dag Hammarskjölds väg 48
> > SE-751 83 Uppsala, Sweden
> > 
> > T: +46 702 80 95 97
> > http://www.aacmicrotec.com
> _______________________________________________
> OpenRISC mailing list
> OpenRISC at lists.librecores.org
> https://lists.librecores.org/listinfo/openrisc
> 

  reply	other threads:[~2017-02-06 13:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-04 20:33 [OpenRISC] Linux openrisc init code Jakob Viketoft
2017-02-05  8:43 ` Stafford Horne
2017-02-05 10:02   ` BAndViG
2017-02-06 13:28     ` Stafford Horne [this message]
2017-02-07  1:03       ` Jakob Viketoft
2017-02-07  2:32         ` Stafford Horne
2017-02-05 10:22   ` Stefan Wallentowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170206132820.GE32144@lianli.shorne-pla.net \
    --to=shorne@gmail.com \
    --cc=openrisc@lists.librecores.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.