Re: [PATCH 8/8] mx25 3ds: add support for boot from UART

[Sascha Hauer <s.hauer@pengutronix.de>]

On Thu, Jun 10, 2010 at 03:42:46PM +0300, Baruch Siach wrote:
> Hi Sascha,
> 
> On Thu, Jun 10, 2010 at 02:12:08PM +0200, Sascha Hauer wrote:
> > On Thu, Jun 10, 2010 at 02:49:39PM +0300, Baruch Siach wrote:
> > > On Thu, Jun 10, 2010 at 01:12:37PM +0200, Sascha Hauer wrote:
> > > > On Wed, Jun 09, 2010 at 10:05:07AM +0300, Baruch Siach wrote:
> > > 
> > > [snip]
> > > 
> > > > > --- a/board/freescale-mx25-3-stack/3stack.c
> > > > > +++ b/board/freescale-mx25-3-stack/3stack.c
> > > > > @@ -44,7 +44,11 @@ extern unsigned long _stext;
> > > > >  
> > > > >  void __naked __flash_header_start go(void)
> > > > >  {
> > > > > +#if defined CONFIG_FREESCALE_MX25_3STACK_UART_BOOT
> > > > > +	__asm__ (".word	exception_vectors\n");
> > > > > +#else
> > > > >  	__asm__ __volatile__("b exception_vectors\n");
> > > > > +#endif
> > > > 
> > > > Do we need this change? I booted other i.MX SoCs without it. I really
> > > > like to keep this because it enables to jump to the first address if
> > > > booting second stage.
> > > 
> > > This is actually a (very) short "flash" header with only the 
> > > app_code_jump_vector entry left. Only reverse engineering the Freescale ATK 
> > > software revealed this secret. Reading through the i.MX25 Reference Manual I 
> > > now see that there is an option to pass DCD separately, but it complicates the 
> > > boot sequence.  This change only affects builds when this configuration 
> > > option, and this option is disabled by default.
> > 
> > What do you use to upload images?
> 
> I use a custom Perl script that parses a .inc file with the same syntax as the 
> those distributed with the Freescale ATK. This script and the .inc file are 
> attached.
> 
> > I once updated my favourite terminal program microcom 
> > (git://git.pengutronix.de/git/tools/microcom) to be
> > able to upload and start images. I didn't need any special images. I
> > just used the ability to write registers to initialize the SDRAM and
> > then uploaded an image to sdram with image type 0xaa which seems to
> > just start the image at the given address.
> 
> What is this "given address"? Is this the same address as the image load 
> address, i.e., the first instruction in the image?

Yes.

> 
> > Find a log attached (which is on an i.MX27, but I tested it on i.MX35 and 
> > i.MX51 aswell) Maybe this could be a solution for you aswell.
> 
> This could really simplify things. Is this support integrated in the git 
> version of microcom?

It is now. It's in the cli-fsl branch.

> 
> Some more question below.
> 
> > Anyway, that said, I can apply your patch, too. I just find it very
> > comfortable to use one image for all boot scenarios.
> > 
> > Sascha
> > 
> > sha@kiwi:~/octopus/microcom/microcom ./microcom -p /dev/ttyS0 -f
> > connected to /dev/ttyS0
> > Escape character: Ctrl-\
> > Type the escape character followed by c to get to the menu or q to quit
> > 
> > barebox:/

Ok, barebox is running here, but...

> > Enter command. Try 'help' for a list of builtin commands

I pressed the escape sequence for microcom here and pushed the reset
button. The board is in UART boot mode now and waits.

> > -> x b

This is to execute a (microcom) script. It just executes the 'mw'
instructions below. (In microcom, they are just named after the barebox
pendants)

> 
> Do you have Barebox running on the board at this point?
> Is the above 'x b' a special microcom command, or a Barebox script?


> 
> I must say that Barebox is much more fun to work with than RedBoot. A huge 
> improvement.

Thanks, nice to hear ;)

> 
> Thanks.
> 
> baruch
> 
> > mw 0xD8001010 0x00000004
> > mw 0xD8001004 0x006ac73a
> > mw 0xD8001000 0x92100000
> > mw 0xA0000f00 0x12344321
> > mw 0xD8001000 0xa2100000
> > mw 0xA0000000 0x12344321
> > mw 0xA0000000 0x12344321
> > mw 0xD8001000 0xb2100000
> > mwb 0xA0000033 0xda
> > mwb 0xA1000000 0xff
> > mw 0xD8001000 0x82226080
> > mw 0xA0000000 0xDEADBEEF
> > mw 0xD8001010 0x0000000c
> > upload 0xa0000000 /home/sha/octopus/barebox/barebox/barebox-pcm038.bin 0xaa
> > image type: 0xaa
> > 
> >     ################################################################
> >     ################################################################
> >     ########################################
> > 
> > ----------------------
> > ����
> > 
> > barebox 2010.04.0-00140-g0a28ada-dirty (Apr 15 2010 - 11:40:21)
> > 
> > Board: Phytec phyCORE-i.MX27
> > cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000
> > NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB
> > 1,8V 8-bit)
> > Bad block table found at page 131040, version 0x01
> > Bad block table found at page 131008, version 0x01
> > imxfb@imxfb0: i.MX Framebuffer driver
> > ULPI Vendor ID 0xffffff92    Product ID 0xffffff92
> > No ISP1504 found
> > ehci@ehci0: USB EHCI 1.00
> > cfi_protect: protect 0xc0040000 (size 131072)
> > 
> > Using environment in NOR Flash
> > initialising PLLs: 0xa7f1ea18 0xa7f291f4
> > Malloc space: 0xa6f00000 -> 0xa7f00000 (size 16 MB)
> > Stack space : 0xa6ef8000 -> 0xa6f00000 (size 32 kB)
> > running /env/bin/init...
> > 
> > Hit any key to stop autoboot:  2
> > 
> > type update_kernel nand|nor [<imagename>] to update kernel into flash
> > type update_root nand|nor [<imagename>] to update rootfs into flash
> > 
> > barebox:/
> 
> -- 
>                                                      ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox