Re: [U-Boot] [PATCH 2/9] MIPS: fix ROM exception vectors
Daniel Schwierzeck writes: > 2016-09-26 9:58 GMT+02:00 Matthew Fortune : > > Daniel Schwierzeck writes: > >> When booting from ROM, early exceptions can't be handled > >> properly. Instead of busy-looping give the developer the > >> possibilty to examine the situation. Thus issue a SDBBP > >> instruction to transfer control to hardware debugger if one > >> is attached. > > > > You could make the SDBBP into a UHI operation that can be read by > > a debugger as an unhandled exception rather than an unexpected > > breakpoint (assuming said debugger knows about UHI). The fragment > > I use in lightweight boot code is: > > > > move k0, t9# Preserve t9 > > move k1, a0# Preserve a0 > > li$25, 15 # UHI exception operation > > li$4, 0 # Use hard register context > > sdbbp 1 # Invoke UHI operation > > > > You lose k0/k1 in this which may be undesirable but it might > > be a reasonable trade off. This shouldn't go in the debug vector > > of course! > > > > sounds interesting. I'll have a look into that. Can I test this with > OpenOCD and GDB? I'm sorry to say progress with getting UHI into OpenOCD is rather slow. The main effort for OpenOCD has been part of the MIPSfpga project which I am not directly involved with. To my knowledge they have the basic 'write' call implemented but are not handling all the operations and the implementation is out of tree. I'll try and check on this and let you know. I had an idea of using a special UHI operation to indicate a boot failure with a simple enumerated 'reason' code so you could get a quick hint at what blew up in low level boot code without the source. I.e. any errors that can be detected without ending up raising an exception. I put two quickly thought up errors into the UHI spec as an example but I only have some simplistic boot code to play with. If you think U-boot could have a range of errors to report like this (and want to use it) then we can add to the list. Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] MIPS: improve start.S and add exception support
Daniel Schwierzeck writes: > will be simply exited. The SDBBP handler currently only > prints the content of registers c0_depc and c0_debug. This > could be extended in the future to handle semi-hosting > according to the MIPS UHI specification. Thanks for considering UHI in this. I worked on a prototype implementation of UHI with Paul that is yet to be submitted which hooks the syscall exception in U-Boot. There is a way to avoid going all the way down to debug mode to process a UHI operation on-target so we can support cores that don't have ejtag or simply to stay out of debug mode wherever possible. The basic principle is that either an application doesn't install its own exception vector and hence uses U-boot's or it does install its own but remembers where U-boot's EBASE was and unwinds a SYSCALL exception and forwards it to U-boot's general-exception handler. It seems to work pretty well but there is certainly no harm in hooking the debug vector too. Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] MIPS: fix ROM exception vectors
Daniel Schwierzeck writes: > When booting from ROM, early exceptions can't be handled > properly. Instead of busy-looping give the developer the > possibilty to examine the situation. Thus issue a SDBBP > instruction to transfer control to hardware debugger if one > is attached. You could make the SDBBP into a UHI operation that can be read by a debugger as an unhandled exception rather than an unexpected breakpoint (assuming said debugger knows about UHI). The fragment I use in lightweight boot code is: move k0, t9# Preserve t9 move k1, a0# Preserve a0 li$25, 15 # UHI exception operation li$4, 0 # Use hard register context sdbbp 1 # Invoke UHI operation You lose k0/k1 in this which may be undesirable but it might be a reasonable trade off. This shouldn't go in the debug vector of course! Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MIPS: Hang if run on a secondary CPU
Paul Burton writes: > Some systems are configured such that multiple CPUs begin running from > their reset vector following a system reset. If this occurs then U-Boot > will be run on multiple CPUs simultaneously, which causes all sorts of > issues as the multiple instances of U-Boot clobber each other. > > Prevent this from happening by simply hanging with an infinite loop if > we run on a CPU whose ID, as determined by GlobalNumber or EBase.CPUNum > as appropriate, is non-zero. > > Signed-off-by: Paul Burton > > --- > > Changes in v2: > - Rebase atop u-boot-mips/next > - Execute a wait instruction in the loop > - Fill delay slots with NOPs > > arch/mips/cpu/start.S| 31 ++- > arch/mips/include/asm/mipsregs.h | 7 +++ > 2 files changed, 37 insertions(+), 1 deletion(-) > > diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S index > 8f85ede..171fbfd 100644 > --- a/arch/mips/cpu/start.S > +++ b/arch/mips/cpu/start.S > @@ -108,9 +108,38 @@ ENTRY(_start) > > .align 4 > reset: > +#if __mips_isa_rev >= 6 > + .setpush > + .setreorder > + mfc0t0, CP0_CONFIG, 1 > + bgezt0, 1f > + mfc0t0, CP0_CONFIG, 2 > + bgezt0, 1f > + mfc0t0, CP0_CONFIG, 3 > + bgezt0, 1f > + mfc0t0, CP0_CONFIG, 4 > + bgezt0, 1f > + mfc0t0, CP0_CONFIG, 5 > + and t0, t0, MIPS_CONF5_VP > + beqzt0, 1f If you want to shorten this a bit: According to MD00090-2B-MIPS32PRA-AFP-06.02 config5 must exist if any feature it describes is implemented and there are features which are mandatory in release6 within config5... therefore config5 is guaranteed to exist on release6 upwards. Matthew > + > + mfc0t0, CP0_GLOBALNUMBER > + b 2f > + .setpop > +#endif > + > +1: mfc0t0, CP0_EBASE > + and t0, t0, EBASE_CPUNUM > + > + /* Hang if this isn't the first CPU in the system */ > + beqzt0, 1f > + nop > +2: wait > + b 2b > + nop > > /* Clear watch registers */ > - MTC0zero, CP0_WATCHLO > +1: MTC0zero, CP0_WATCHLO > mtc0zero, CP0_WATCHHI > > /* WP(Watch Pending), SW0/1 should be cleared */ diff --git > a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h > index b4c2dff..9ab5063 100644 > --- a/arch/mips/include/asm/mipsregs.h > +++ b/arch/mips/include/asm/mipsregs.h > @@ -39,6 +39,7 @@ > #define CP0_ENTRYLO0 $2 > #define CP0_ENTRYLO1 $3 > #define CP0_CONF $3 > +#define CP0_GLOBALNUMBER $3, 1 > #define CP0_CONTEXT $4 > #define CP0_PAGEMASK $5 > #define CP0_WIRED $6 > @@ -361,6 +362,11 @@ > #define CAUSEF_BD(_ULCAST_(1) << 31) > > /* > + * Bits in the coprocessor 0 EBase register. > + */ > +#define EBASE_CPUNUM 0x3ff > + > +/* > * Bits in the coprocessor 0 config register. > */ > /* Generic bits. */ > @@ -553,6 +559,7 @@ > #define MIPS_CONF5_MRP (_ULCAST_(1) << 3) > #define MIPS_CONF5_LLB (_ULCAST_(1) << 4) > #define MIPS_CONF5_MVH (_ULCAST_(1) << 5) > +#define MIPS_CONF5_VP(_ULCAST_(1) << 7) > #define MIPS_CONF5_FRE (_ULCAST_(1) << 8) > #define MIPS_CONF5_UFE (_ULCAST_(1) << 9) > #define MIPS_CONF5_L2C (_ULCAST_(1) << 10) > -- > 2.10.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: fix mips_cache fallback without __builtin_mips_cache
Matthias Schiffer writes:
> >
> > I've disabled the builtin code and compared dissaemblies with and
> without your patch. Without your patch, gcc adds an additional store
> instruction before each cache instruction.
> >
> > E.g. for flush_dcache_range():
> >
> > 18: afa20008sw v0,8(sp)
> > 1c: bfb50008cache 0x15,8(sp)
> >
> > vs.
> >
> > 14: bc55cache 0x15,0(v0)
> >
> > The cache operation works anyway, but with your patch better code is
> generated.
>
> If I understand this correctly, the code without my patch would rather
> invalidate the cache for the address 8(sp), which is part of the stack,
> and not the memory pointed at by v0.
Matthias is correct. These two code sequences will exhibit different
overall behaviour. The latter is much more likely to be what you wanted
from what I can see as the flush is to operate on the value of the
'addr' variable not the address of the addr variable.
The same behaviour could be achieved with:
__asm__ __volatile__("cache %0, %1" : : "i"(op), "R"(addr));
and
__asm__ __volatile__("cache %0, 0(%1)" : : "i"(op), "r"(&addr));
Hope that's useful.
Matthew
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS UHI spec
James Hogan writes: > On 26/02/15 12:37, Daniel Schwierzeck wrote: > > 2015-02-26 11:17 GMT+01:00 Paul Burton : > >> On Thu, Feb 19, 2015 at 01:50:23PM +0000, Matthew Fortune wrote: > >>> Hi Daniel, > >>> > >>> The spec for MIPS Unified Hosting Interface is available here: > >>> > >>> http://prplfoundation.org/wiki/MIPS_documentation > >>> > >>> As we have previously discussed, this is an ideal place to define > >>> the handover of device tree data from bootloader to kernel. Using a0 > >>> == -2 and defining which register(s) you need for the actual data > >>> will fit nicely. I'll happily include whatever is decided into the > >>> next version of the spec. > > > > this originates from an off-list discussion some months ago started by > > John Crispin. > > > > (CC +John, Ralf, Jonas, linux-mips) > > > >> > >> (CC +Andrew, Ezequiel, James, James) > >> > >> On the talk of DT handover, this recent patchset adding support for a > >> system doing so to Linux is relevant: > >> > >> > >> http://www.linux-mips.org/archives/linux-mips/2015-02/msg00312.html > >> > >> I'm also working on a system for which I'll need to implement DT > >> handover very soon. It would be very nice if we could agree on some > >> standard way of doing so (and eventually if the code on the Linux > >> side can be generic enough to allow a multiplatform kernel). > >> > > > > to be conformant with UHI I propose $a0 == -2 and $a1 == address of DT > > blob. It is a simple extension and should not interfere with the > > various legacy boot interfaces. > > I was just looking at Andrew's patch: > http://patchwork.linux-mips.org/patch/9549/ > > How would the other registers (i.e. $a2 and $a3) be defined for this > boot interface? I'm guessing any future extensions are envisioned to use > a different negative value of $a0, in which case treating them as > unused/undefined is fine, but perhaps that should be spelt out in the > UHI spec? Sounds sensible. Making it explicit may help prevent anyone extending this and presuming that they can give meaning to one of the unused registers. Did anyone come to a conclusion on physical vs virtual address for the DTB? I forgot to reply to the thread, I would have thought the KSEG0 address would be the obvious choice so that it is immediately usable from ordinary memory accesses. However, that is only because I don't follow how the kernel would benefit from being given a physical address. It can't be remapped except for the case of segmentation control (I believe) so there seems little risk in using KSEG0. Thanks, Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MIPS UHI spec
Hi Daniel, The spec for MIPS Unified Hosting Interface is available here: http://prplfoundation.org/wiki/MIPS_documentation As we have previously discussed, this is an ideal place to define the handover of device tree data from bootloader to kernel. Using a0 == -2 and defining which register(s) you need for the actual data will fit nicely. I'll happily include whatever is decided into the next version of the spec. This is also the spec I would like to use to implement a syscall interface. Previous post on the topic: http://lists.denx.de/pipermail/u-boot/2014-December/198007.html Only a subset of the operations would be implemented for u-boot and would be strictly limited to sit on top of the functionality that is already exposed to standalone applications with GPL exceptions. Some of the operations need a bit of wrapper code around the API functions i.e. The write operation would only be handled for FD 1 and 2 and would be implemented as a loop sending each byte of the buffer via putc. UHI also provides a semi-hosting solution for u-boot itself which it could use to obtain files over the EJTAG interface. Initial implementation of the syscall interface will be posted relatively soon. Thanks, Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Implementing the uBoot SYSCALL interface for MIPS
Hi Daniel, I'm looking for a bit of feedback on my query below. Unless there is a major problem I'll start to organise an implementation for review. Thanks, Matthew > -Original Message- > From: Matthew Fortune > Sent: 08 December 2014 12:43 > To: 'u-boot@lists.denx.de' > Subject: Implementing the uBoot SYSCALL interface for MIPS > > Hi all, > > I've been recently working on and promoting a common bare-metal semi- > hosting interface for the MIPS architecture. The main goal of this is to > allow a bare-metal MIPS application to run on the maximum number of > simulation and hardware platforms without (much/any) modification. The > interface uses the MIPS SYSCALL interface and a custom ABI to request > operations from an OS or monitor. > > As far as I can see uBoot's new(ish) API as not yet been mapped onto the > MIPS architecture. I would like to find out if it will be acceptable to > access some map some of the operations from the semi-hosting interface > onto the uBoot API. > > In particular I'd like to get: open, read, write, close, fstat > implemented such that FD 0/1 behave as if attached to a serial port. > Open/close and fstat wouldn't do anything special as they would just say > that FD 0/1 exist. > Read and write would map to getc and putc for FD 0 and FD 1 > respectively. > > The interface is being implemented directly in qemu, and as part of > libgloss on the consumer side (not upstream yet). I will be promoting > its use in any other open source simulators and hosting libraries too as > I find them. I'm also boldly trying to abstract away from any ABI issues > (O32/N32/N64) to potentially allow the consumer and producer side of the > interface to have different ABIs to some extent. I am also trying to > create a well-defined entry-point interface to reduce the variance in > how arguments are passed from bootloader to application, at least one > person has shown interest in this from the kernel list. > > If it sounds like it will be acceptable then I'll send more details of > the interface as a follow up but I would really like to include uBoot in > the list of supported environments. There is of course scope to add any > number of extra operations to the interface to cover more of the uBoot > API but I generally agree with the principle that exploiting too much of > uBoot is bad form if an application is non-GPL. > > Thanks, > Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Implementing the uBoot SYSCALL interface for MIPS
Hi all, I've been recently working on and promoting a common bare-metal semi-hosting interface for the MIPS architecture. The main goal of this is to allow a bare-metal MIPS application to run on the maximum number of simulation and hardware platforms without (much/any) modification. The interface uses the MIPS SYSCALL interface and a custom ABI to request operations from an OS or monitor. As far as I can see uBoot's new(ish) API as not yet been mapped onto the MIPS architecture. I would like to find out if it will be acceptable to access some map some of the operations from the semi-hosting interface onto the uBoot API. In particular I'd like to get: open, read, write, close, fstat implemented such that FD 0/1 behave as if attached to a serial port. Open/close and fstat wouldn't do anything special as they would just say that FD 0/1 exist. Read and write would map to getc and putc for FD 0 and FD 1 respectively. The interface is being implemented directly in qemu, and as part of libgloss on the consumer side (not upstream yet). I will be promoting its use in any other open source simulators and hosting libraries too as I find them. I'm also boldly trying to abstract away from any ABI issues (O32/N32/N64) to potentially allow the consumer and producer side of the interface to have different ABIs to some extent. I am also trying to create a well-defined entry-point interface to reduce the variance in how arguments are passed from bootloader to application, at least one person has shown interest in this from the kernel list. If it sounds like it will be acceptable then I'll send more details of the interface as a follow up but I would really like to include uBoot in the list of supported environments. There is of course scope to add any number of extra operations to the interface to cover more of the uBoot API but I generally agree with the principle that exploiting too much of uBoot is bad form if an application is non-GPL. Thanks, Matthew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
