[U-Boot] [RFC PATCH 0/1] SPL JTAG boot mode

[U-Boot] [RFC PATCH 0/1] SPL JTAG boot mode

[Michal Simek]

Hi,

I have got this patch some time ago but I am not still
100% sure about use case. Anyway Soren uses this mode
that's why let me send this patch and we can discuss
if this can be useful for someone else too.

The use case is to load U-Boot SPL to do init HW
and then load images via JTAG because RAM is initialized
and then run full u-boot.
There is an option to do HW initialization without
U-Boot SPL but there are some differences and it is just
better to directly use code which will run on the board
when everything is tested.

Thanks for your inputs,
Michal


Michal Simek (1):
  ARM: spl: Introduce JTAG mode

 arch/arm/include/asm/spl.h        | 1 +
 arch/microblaze/include/asm/spl.h | 1 +
 common/spl/spl.c                  | 7 +++++++
 3 files changed, 9 insertions(+)

--
1.8.2.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140811/b6b33e71/attachment.pgp>

[U-Boot] [RFC PATCH] ARM: spl: Introduce JTAG mode

[Michal Simek]

Introduce simple JTAG mode which stops CPU
before U-Boot image processing.

Signed-off-by: Ezra Savard <ezra.savard@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
---

 arch/arm/include/asm/spl.h        | 1 +
 arch/microblaze/include/asm/spl.h | 1 +
 common/spl/spl.c                  | 7 +++++++
 3 files changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h
index e5daf8912712..d690c5914f05 100644
--- a/arch/arm/include/asm/spl.h
+++ b/arch/arm/include/asm/spl.h
@@ -26,6 +26,7 @@ enum {
 	BOOT_DEVICE_SPI,
 	BOOT_DEVICE_SATA,
 	BOOT_DEVICE_I2C,
+	BOOT_DEVICE_JTAG,
 	BOOT_DEVICE_NONE
 };
 #endif
diff --git a/arch/microblaze/include/asm/spl.h b/arch/microblaze/include/asm/spl.h
index c1cae6cf0fe6..3715f4862a01 100644
--- a/arch/microblaze/include/asm/spl.h
+++ b/arch/microblaze/include/asm/spl.h
@@ -12,5 +12,6 @@
 #define BOOT_DEVICE_RAM		1
 #define BOOT_DEVICE_NOR		2
 #define BOOT_DEVICE_SPI		3
+#define BOOT_DEVICE_JTAG	4

 #endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 774fdad2523b..de1de880b738 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -215,6 +215,13 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 		spl_sata_load_image();
 		break;
 #endif
+#ifdef CONFIG_SPL_JTAG_SUPPORT
+	case BOOT_DEVICE_JTAG:
+		debug("Ready for image");
+		while (1)
+			;
+		break;
+#endif
 	default:
 		debug("SPL: Un-supported Boot Device\n");
 		hang();
--
1.8.2.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140811/b95917d2/attachment.pgp>

[U-Boot] [RFC PATCH 0/1] SPL JTAG boot mode

[Tom Rini]

On Mon, Aug 11, 2014 at 03:03:35PM +0200, Michal Simek wrote:

> Hi,
> 
> I have got this patch some time ago but I am not still
> 100% sure about use case. Anyway Soren uses this mode
> that's why let me send this patch and we can discuss
> if this can be useful for someone else too.
> 
> The use case is to load U-Boot SPL to do init HW
> and then load images via JTAG because RAM is initialized
> and then run full u-boot.
> There is an option to do HW initialization without
> U-Boot SPL but there are some differences and it is just
> better to directly use code which will run on the board
> when everything is tested.

So in this case, you attach JTAG to the board, halt on reset, reset the
board.  JTAG load in SPL and fiddle memory so that BOOT_DEVICE_JTAG is
set, let SPL run, halt when you see the print (or set a breakpoint for
that part, either way), then load U-Boot via JTAG, resume over the while
loop, and then debug U-Boot as needed?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140811/bfae219c/attachment.pgp>

[U-Boot] [RFC PATCH 0/1] SPL JTAG boot mode

[Michal Simek]

On 08/11/2014 03:17 PM, Tom Rini wrote:
> On Mon, Aug 11, 2014 at 03:03:35PM +0200, Michal Simek wrote:
> 
>> Hi,
>>
>> I have got this patch some time ago but I am not still
>> 100% sure about use case. Anyway Soren uses this mode
>> that's why let me send this patch and we can discuss
>> if this can be useful for someone else too.
>>
>> The use case is to load U-Boot SPL to do init HW
>> and then load images via JTAG because RAM is initialized
>> and then run full u-boot.
>> There is an option to do HW initialization without
>> U-Boot SPL but there are some differences and it is just
>> better to directly use code which will run on the board
>> when everything is tested.
> 
> So in this case, you attach JTAG to the board, halt on reset, reset the
> board.  JTAG load in SPL and fiddle memory so that BOOT_DEVICE_JTAG is
> set, let SPL run, 

BOOT_DEVICE_JTAG for zynq case will be setup in spl_boot_device() based on
dip-switch boot mode setup read from SLCR.

> halt when you see the print (or set a breakpoint for
> that part, either way), then load U-Boot via JTAG, resume over the while
> loop, and then debug U-Boot as needed?

In general that's my impression how Soren uses it.
I would let him to confirm that this is his use case.

Not sure if he is just loading images when cpu is in while(1) loop
and let u-boot spl continue. I can imagine that it will be just easier
to let u-boot spl end up in while loop instead of trying to find out
address for adding breakpoint.

I would let Soren or Ezra to justify this use case because I have doubts.

Thanks,
Michal

[U-Boot] [RFC PATCH 0/1] SPL JTAG boot mode

[Ezra Savard]

> -----Original Message-----
> From: Michal Simek [mailto:michal.simek at xilinx.com]
> Sent: Monday, August 11, 2014 6:30 AM
> To: Tom Rini; Michal Simek
> Cc: u-boot at lists.denx.de; Stephen Warren; Ezra Savard; Soren
> Brinkmann; Roger Quadros
> Subject: Re: [U-Boot] [RFC PATCH 0/1] SPL JTAG boot mode
>
> On 08/11/2014 03:17 PM, Tom Rini wrote:
> > On Mon, Aug 11, 2014 at 03:03:35PM +0200, Michal Simek wrote:
> >
> >> Hi,
> >>
> >> I have got this patch some time ago but I am not still 100% sure
> >> about use case. Anyway Soren uses this mode that's why let me send
> >> this patch and we can discuss if this can be useful for someone
> >> else too.
> >>
> >> The use case is to load U-Boot SPL to do init HW and then load
> >> images via JTAG because RAM is initialized and then run full u-boot.
> >> There is an option to do HW initialization without U-Boot SPL but
> >> there are some differences and it is just better to directly use
> >> code which will run on the board when everything is tested.
> >
> > So in this case, you attach JTAG to the board, halt on reset, reset
> > the board.  JTAG load in SPL and fiddle memory so that
> > BOOT_DEVICE_JTAG is set, let SPL run,
>
> BOOT_DEVICE_JTAG for zynq case will be setup in spl_boot_device()
> based on dip-switch boot mode setup read from SLCR.
>
> > halt when you see the print (or set a breakpoint for that part,
> > either way), then load U-Boot via JTAG, resume over the while loop,
> > and then debug U-Boot as needed?
>
> In general that's my impression how Soren uses it.
> I would let him to confirm that this is his use case.
>
> Not sure if he is just loading images when cpu is in while(1) loop and
> let u- boot spl continue. I can imagine that it will be just easier to
> let u-boot spl end up in while loop instead of trying to find out address for adding breakpoint.
>
In our use case, we do not have physical access to the board.

Previously, u-boot spl would hang when ready for the u-boot image; the
explicit JTAG boot mode keeps from attempting to load images from RAM.

The while(1) loop is, as mentioned by Michal, just an easy, known place to let
the u-boot spl end up before loading images.

Soren will be back in one week and it would be best for him to chime in.

Thanks,
Ezra

> I would let Soren or Ezra to justify this use case because I have doubts.
>
> Thanks,
> Michal



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

[U-Boot] [RFC PATCH 0/1] SPL JTAG boot mode

[Sören Brinkmann]

On Mon, 2014-08-11 at 09:17AM -0400, Tom Rini wrote:
> On Mon, Aug 11, 2014 at 03:03:35PM +0200, Michal Simek wrote:
> 
> > Hi,
> > 
> > I have got this patch some time ago but I am not still
> > 100% sure about use case. Anyway Soren uses this mode
> > that's why let me send this patch and we can discuss
> > if this can be useful for someone else too.
> > 
> > The use case is to load U-Boot SPL to do init HW
> > and then load images via JTAG because RAM is initialized
> > and then run full u-boot.
> > There is an option to do HW initialization without
> > U-Boot SPL but there are some differences and it is just
> > better to directly use code which will run on the board
> > when everything is tested.
> 
> So in this case, you attach JTAG to the board, halt on reset, reset the
> board.  JTAG load in SPL and fiddle memory so that BOOT_DEVICE_JTAG is
> set, let SPL run, halt when you see the print (or set a breakpoint for
> that part, either way), then load U-Boot via JTAG, resume over the while
> loop, and then debug U-Boot as needed?

That is pretty much the flow correct. But I do not use it to debug
U-Boot, but boot our boards in our boardfarm. The flow is

1. Connect JTAG debugger
2. Download and run SPL
3. Stop execution when the SPL is done (and did initialize the DDR)
4. Load U-Boot and run U-Boot through JTAG
5. boot full OS etc.

I.e. the JTAG boot flow is used in automation quite a lot here.

	Thanks,
	S?ren