* [OpenRISC] Linux openrisc init code... @ 2017-02-04 20:33 Jakob Viketoft 2017-02-05 8:43 ` Stafford Horne 0 siblings, 1 reply; 7+ messages in thread From: Jakob Viketoft @ 2017-02-04 20:33 UTC (permalink / raw) To: openrisc 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. :) 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. 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. 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [OpenRISC] Linux openrisc init code... 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-05 10:22 ` Stefan Wallentowitz 0 siblings, 2 replies; 7+ messages in thread From: Stafford Horne @ 2017-02-05 8:43 UTC (permalink / raw) To: openrisc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [OpenRISC] Linux openrisc init code... 2017-02-05 8:43 ` Stafford Horne @ 2017-02-05 10:02 ` BAndViG 2017-02-06 13:28 ` Stafford Horne 2017-02-05 10:22 ` Stefan Wallentowitz 1 sibling, 1 reply; 7+ messages in thread From: BAndViG @ 2017-02-05 10:02 UTC (permalink / raw) To: openrisc 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. 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 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? 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [OpenRISC] Linux openrisc init code... 2017-02-05 10:02 ` BAndViG @ 2017-02-06 13:28 ` Stafford Horne 2017-02-07 1:03 ` Jakob Viketoft 0 siblings, 1 reply; 7+ messages in thread From: Stafford Horne @ 2017-02-06 13:28 UTC (permalink / raw) To: openrisc 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [OpenRISC] Linux openrisc init code... 2017-02-06 13:28 ` Stafford Horne @ 2017-02-07 1:03 ` Jakob Viketoft 2017-02-07 2:32 ` Stafford Horne 0 siblings, 1 reply; 7+ messages in thread From: Jakob Viketoft @ 2017-02-07 1:03 UTC (permalink / raw) To: openrisc Hi Andrey and Stafford, Sorry for my late reply, a trip to Japan with some jet lag got in the way. >> 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 Yes, this is what I'm talking about. By giving the boot address as 0x100, the kernel wasn't able to use the dtb before since it used r3 and r4 to compute the address of the _start vector (in head.S). In linux-next, I can see this has been changed to r13 and r15 and you shouldn't need to worry about this anymore. My address of 0x400000 was due to an internal setup with several different images (and dtb's) in flash. Anyway, ignore the rumble of old times. :) >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. Flash in our case, allows us to have a generic image, but different dtb's on different boards. 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [OpenRISC] Linux openrisc init code... 2017-02-07 1:03 ` Jakob Viketoft @ 2017-02-07 2:32 ` Stafford Horne 0 siblings, 0 replies; 7+ messages in thread From: Stafford Horne @ 2017-02-07 2:32 UTC (permalink / raw) To: openrisc Hello, On Tue, Feb 07, 2017 at 01:03:59AM +0000, Jakob Viketoft wrote: > Hi Andrey and Stafford, > > Sorry for my late reply, a trip to Japan with some jet lag got in the way. Are you still here? I live in japan (Tokyo). Send me a message if you are here and need any tips or want to go out :) > >> 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 > > Yes, this is what I'm talking about. By giving the boot address as 0x100, the kernel wasn't able to use the dtb before since it used r3 and r4 to compute the address of the _start vector (in head.S). In linux-next, I can see this has been changed to r13 and r15 and you shouldn't need to worry about this anymore. My address of 0x400000 was due to an internal setup with several different images (and dtb's) in flash. Anyway, ignore the rumble of old times. :) Oh great, thanks for having a look. > >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. > > Flash in our case, allows us to have a generic image, but different dtb's on different boards. Understood. -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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [OpenRISC] Linux openrisc init code... 2017-02-05 8:43 ` Stafford Horne 2017-02-05 10:02 ` BAndViG @ 2017-02-05 10:22 ` Stefan Wallentowitz 1 sibling, 0 replies; 7+ messages in thread From: Stefan Wallentowitz @ 2017-02-05 10:22 UTC (permalink / raw) To: openrisc On 05.02.2017 09:43, Stafford Horne wrote: > 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 think this was inherited from OR1200. I left it in newlib because I saw errors when simulating with modelsim and inititalizing regs and memory to 'x. Then r0 was also 'x and the boot failed. Cheers, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20170205/7986539e/attachment.sig> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-07 2:32 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2017-02-07 1:03 ` Jakob Viketoft 2017-02-07 2:32 ` Stafford Horne 2017-02-05 10:22 ` Stefan Wallentowitz
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.