[U-Boot-Users] The i386 patch

[U-Boot-Users] The i386 patch

[Daniel Engström]

Hello all

I realize that I threw the figure around yesterdag it was 83kb rather than 
38...
Todays, cleanup version measure in at 62kb.

I hope you'll like it :)

Wolfgang:
This patch touch common code in a few places, nothing to controversion, I 
hope.

/Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppcboot-i386-021113.diff.gz
Type: application/x-gzip
Size: 62748 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20021113/472f40ae/attachment.bin 

[U-Boot-Users] Re: The i386 patch

[Wolfgang Denk]

Dear Daniel,

in message <20021113094454.G22221@jupiter.omicron.se> you wrote:
> 
> I realize that I threw the figure around yesterdag it was 83kb rather than 
> 38...
> Todays, cleanup version measure in at 62kb.
> 
> I hope you'll like it :)

Thanks again for the patch.

> Wolfgang:
> This patch touch common code in a few places, nothing to controversion, I 
> hope.



I tried to merge your patch with the current U-Boot code; I still get
a _LOT_ of warnings,  and  unresolved  references  from  the  strings
functions, but I think you can pick up here...



A few comments:

* Please, do not add trailing white space to existing code!

* Always make sure to run the MAKEALL  script;  this  catches  errors
  like this one:

-               void *to = (void *)ntohl(hdr->ih_load);
+               void *to = (void *)ntohl(hdr->ih_load));

* Do not use C++ style comments



Comments on specific parts of the patch:

common/cmd_bootm.c:

        x86 should _not_ need any special code here. Do you think  it
        is  possible to add support for "standard" mkimage format and
        get rid of your new #ifdef's?



	Added with minor modifications:

	@@ -145,10 +163,11 @@
			SHOW_BOOT_PROGRESS (-2);
			return 1;
		}
	+       hdr->ih_hcrc = htonl(checksum);
		SHOW_BOOT_PROGRESS (3);

	I don't understand why this could be needed; omitted.


common/cmd_ide.c:

	+#ifdef __PPC__
	 #define        ATA_CURR_BASE(dev)      (CFG_ATA_BASE_ADDR+ide_bus_offset[IDE_BUS(dev
	 )])
	+#endif
	...
	+#ifdef __PPC__
	 static void input_swap_data(int dev, ulong *sect_buf, int words);
	+#endif


	Are you sure this is PPC only?


ppcboot/examples/syscall.S:

	Are you sure there is only a "ret" needed?



include/asm-arm/string.h:
lib_generic/string.c:

        Why do you modify ARM and generic files? I want to keep  this
        file as close as possible in sync with standard Linux code.

	*** NOT accepted ***

        This breaks include/asm-i386/string.h - can you please try to
        fix this instead?



I've checked the current state in on the U-Boot CVS server.  The  tag
is  LABEL_2002_11_18_0115 . Can you please have a look at it and help
to clean it up?

TIA!

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Severe culture shock results when experts from another protocol suite
[...] try to read OSI documents. The term "osified" is used to  refer
to  such  documents. [...] Any relationship to the word "ossified" is
purely intentional.                                - Marshall T. Rose

[U-Boot-Users] Re: The i386 patch

[Daniel Engström]

Wolfgang,

On 2002.11.18 01:15 Wolfgang Denk wrote:
> Comments on specific parts of the patch:
> 
> common/cmd_bootm.c:
> 
>         x86 should _not_ need any special code here. Do you think  it
>         is  possible to add support for "standard" mkimage format and
>         get rid of your new #ifdef's?
The "standard" mkimage format IS supported, this code add support for Linux
images without the mkimage header as well.
If you do not need any of the features in the image header the header it 
slef is just
an extra source of problems, for example the load address is bogus for 
i386 I would like
to have an option to ignore it completly for Linux image and always load 
at a safe place.
This is currently what happens if you boot a kernel with out the image 
header.
Or better yet not load the kernel at all if the kernel resides in flash,
just give do_bootm_linux() a pointer to where the kernel is located.

Right now do_bootm() loads the kernel from flash and do_bootm_linux() 
moves it to the correct
location.

The fisrt part, setup should be loaded at 0x90000 (size may vary between 
2.5k and 32k), the rest of the kernel should be loaded at 0x10000 if it is 
a zImage or 0x100000 if it
is a bzImage.

0xa0000-0xfffff is ROM and memory mapped I/O area, so loading the entire 
thing at
0x90000 will fail as well.

  
> 	Added with minor modifications:
> 
> 	@@ -145,10 +163,11 @@
> 			SHOW_BOOT_PROGRESS (-2);
> 			return 1;
> 		}
> 	+       hdr->ih_hcrc = htonl(checksum);
> 		SHOW_BOOT_PROGRESS (3);
> 
> 	I don't understand why this could be needed; omitted.
OK, I saw that it was referenced below in the function, but it seems to be 
when
the ramdisk-image gets loaded, so that would be another header. 
> common/cmd_ide.c:
> 	+#ifdef __PPC__
> 	Are you sure this is PPC only?
No, I thought that ide was only used by ppc before, but I se now that IDE 
is used
by the ARM as well.
Should perhaps be #ifdef __BIG_ENDIAN ?

> 
> ppcboot/examples/syscall.S:
> 
> 	Are you sure there is only a "ret" needed?
Its a place holder, syscalls are not functional yet.
I think it will be a problem that printf is defined as a
syscall because it is a variable argument list function.

How do I know how much of the stack to copy when I enter
the firmware?

   /Daniel
  

[U-Boot-Users] Re: The i386 patch

[Wolfgang Denk]

Dear Daniel,

in message <20021118113139.E892@jupiter.omicron.se> you wrote:
> 
> >         x86 should _not_ need any special code here. Do you think  it
> >         is  possible to add support for "standard" mkimage format and
> >         get rid of your new #ifdef's?
> The "standard" mkimage format IS supported, this code add support for Linux
> images without the mkimage header as well.

I see.

> Or better yet not load the kernel at all if the kernel resides in flash,
> just give do_bootm_linux() a pointer to where the kernel is located.

Right. This is something which I probably  should  fix  on  PPC,  too
(fixed on ARM some time ago).

> > common/cmd_ide.c:
> > 	+#ifdef __PPC__
> > 	Are you sure this is PPC only?
> No, I thought that ide was only used by ppc before, but I se now that IDE 
> is used
> by the ARM as well.
> Should perhaps be #ifdef __BIG_ENDIAN ?

But ARM is little endian!

> > ppcboot/examples/syscall.S:
> > 
> > 	Are you sure there is only a "ret" needed?
> Its a place holder, syscalls are not functional yet.

Then we should rather have a #warning similar to the  current  styate
in ARM.

> I think it will be a problem that printf is defined as a
> syscall because it is a variable argument list function.
> 
> How do I know how much of the stack to copy when I enter
> the firmware?

What do you mean with "stack to copy"? You are running in the  U-Boot
environment,  accessing  the  U-Boot  stack directly. No need to copy
anything...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The high cost of living hasn't affected its popularity.

[U-Boot-Users] Re: The i386 patch

[Robert Kaiser]

Am Dienstag, 19. November 2002 22:19 schrieb Wolfgang Denk:
> > I think it will be a problem that printf is defined as a
> > syscall because it is a variable argument list function.
> >
> > How do I know how much of the stack to copy when I enter
> > the firmware?
>
> What do you mean with "stack to copy"?

The standard method for the x86 to implement a syscall is through a 
"gate", which is also a mechanism to switch to a higher protection level. 
Since caller and callee run at different protection levels, they use 
different stacks and since the x86 passes arguments on the stack, it is 
possible to specify (in the corresponding gate structure) the amount of bytes 
to be copied from the caller's stack to the callee's stack.

> You are running in the  U-Boot
> environment,  accessing  the  U-Boot  stack directly. No need to copy
> anything...

Does that mean that the caller always runs at the same protection level as 
U-Boot?

If so, then I think that a syscall mechanism for the x86 through gates would 
be overkill. But then, OTOH, why use syscalls at all ? A simple jump table 
could do the same thing, and do it portably.

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser at sysgo.de
SYSGO AG
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10

[U-Boot-Users] Re: The i386 patch

[Wolfgang Denk]

In message <200211201114.gAKBEss01326@dagobert.svc.sysgo.de> you wrote:
>
> > What do you mean with "stack to copy"?
> 
> The standard method for the x86 to implement a syscall is through a 
> "gate", which is also a mechanism to switch to a higher protection level. 
> Since caller and callee run at different protection levels, they use 

OK, understood.

But this is not what U-Boot needs.

> Does that mean that the caller always runs at the same protection level as 
> U-Boot?

Right.

> If so, then I think that a syscall mechanism for the x86 through gates would 
> be overkill. But then, OTOH, why use syscalls at all ? A simple jump table 
> could do the same thing, and do it portably.

You may remember that we used a jump table  attached  to  the  global
data in early versions of PPCBoot. I didn't like this. The nice thing
about  the  syscall  trap  on  PPC is that you can easily put a "jump
table" at a well-known location, so that a standalone application can
access certain services (those explicitely exported by  U-Boot  using
the  syscall  interface)  without  depending  on  a  special software
version.

I have to admit that I did not think about other architectures at the
time we implemented this.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Remember that Beethoven wrote his first symphony in C ...

[U-Boot-Users] Re: The i386 patch

[Daniel Engström]

On 2002.11.20 15:06 Wolfgang Denk wrote:
> In message <200211201114.gAKBEss01326@dagobert.svc.sysgo.de> you wrote:

> You may remember that we used a jump table  attached  to  the  global
> data in early versions of PPCBoot. I didn't like this. The nice thing
> about  the  syscall  trap  on  PPC is that you can easily put a "jump
> table" at a well-known location, so that a standalone application can
> access certain services (those explicitely exported by  U-Boot  using
> the  syscall  interface)  without  depending  on  a  special software
> version.
> 
> I have to admit that I did not think about other architectures at the
> time we implemented this.

The i386 can do indirect calls on the ebp register. So we could let the
application know the location of the syscall table by providing it in a
register on entry. The applications initialization code can then store
it in a suitable location (called syscall_table below).

The syscall would than be done like this:

movl    $SYSCALL_NR, %eax
movl    syscall_table, %ebp
shll    $2, %eax
addl    %eax, %ebp
call    *%ebp
ret

/Daniel

[U-Boot-Users] Re: The i386 patch

[Robert Kaiser]

Am Mittwoch, 20. November 2002 15:06 schrieben Sie:
> In message <200211201114.gAKBEss01326@dagobert.svc.sysgo.de> you wrote:
>
> [explanation of x86 gate mechanism ..]
>
> But this is not what U-Boot needs.

I thought so :-)

> You may remember that we used a jump table  attached  to  the  global
> data in early versions of PPCBoot. I didn't like this. The nice thing
> about  the  syscall  trap  on  PPC is that you can easily put a "jump
> table" at a well-known location, so that a standalone application can
> access certain services (those explicitely exported by  U-Boot  using
> the  syscall  interface)  without  depending  on  a  special software
> version.

So, essentially, the syscall mechanism in U-Boot/PPC is just a jump table at 
a well known location, where that location is defined by the architecture, 
right ?

This surely makes sense, but I'm not sure wether it should be adopted as a 
model for the other architectures.

Why not do it as the good old OS-9 or pSOS did: identify one absolute address 
that is otherwise unused (every architecture has this in some form: an unused 
trap vector, unused word in space reserved for first level exception handler, 
etc.). In that location, have U-boot publish the address of the jump table at 
startup time (by storing a pointer to it). This is actually no different from 
the trap mechanism used by the PPC, except that the "well-known location" is 
defined by convention rather than by the hardware. And this could be done 
portably.

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser at sysgo.de
SYSGO AG
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10

[U-Boot-Users] Re: The i386 patch

[Robert Kaiser]

Am Mittwoch, 20. November 2002 15:18 schrieb Daniel Engstr?m:
>
> The i386 can do indirect calls on the ebp register. So we could let the
> application know the location of the syscall table by providing it in a
> register on entry. The applications initialization code can then store
> it in a suitable location (called syscall_table below).
>
> The syscall would than be done like this:
>
> movl    $SYSCALL_NR, %eax
> movl    syscall_table, %ebp
> shll    $2, %eax
> addl    %eax, %ebp
> call    *%ebp
> ret
>

Exactly, except that I would do it in C:

---------------------------- cut here ----------------------------
/*
** The U-Boot's anchor :-)
** This is an absolute address that is otherwise unused.
** U-boot sets it to contain the address of the syscall
** jumptable, so clients can make calls into U-boot.
*/
#define UBOOT_ANCHOR	0x.....

struct syscall_jmptbl {
	int  (*j_mon_getc)(void);
	int  (*j_mon_tstc)(void);
	void (*j_mon_putc)(const char);
	void (*j_mon_puts)(const char*);
	void (*j_mon_printf)(const char* fmt, ...);
	void (*j_mon_install_hdlr)(int, interrupt_handler_t*, void*);
	void (*j_mon_free_hdlr)(int);
	void *(*j_mon_malloc)(size_t);
	void (*j_mon_free)(void*);
	void (*j_mon_udelay)(unsigned long);
	unsigned long (*j_mon_get_timer)(unsigned long);
};

... in U-BOOT startup:

static struct syscall_jmptbl jmptable;

...

	jmptable.j_mon_getc = mon_getc;
	jmptable.j_mon_tstc = mon_tstc;
	jmptable.j_mon_putc = mon_putc;
	jmptable.j_mon_puts = mon_puts;
	jmptable.j_mon_printf = mon_printf;
	jmptable.j_mon_install_hdlr = mon_install_hdlr;
	jmptable.j_mon_free_hdlr = mon_free_hdlr;
	jmptable.j_mon_malloc = mon_malloc;
	jmptable.j_mon_free = mon_free;
	jmptable.j_mon_udelay = mon_udelay;
	jmptable.j_mon_get_timer= mon_get_timer;


	/* publish location of jump table */
	*((struct syscall_jmptbl**)UBOOT_ANCHOR) = &jmptable;

....


in client:

	struct syscall_jmptbl *tbl;


	tbl = *((struct syscall_jmptbl**)UBOOT_ANCHOR);

	tbl->j_mon_printf("Hello\n");


...
---------------------------- cut here ----------------------------



This would essentially do the same thing, but it should work on all platforms.

Rob


----------------------------------------------------------------
Robert Kaiser                         email: rkaiser at sysgo.de
SYSGO AG
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10