RE: [U-Boot-Users] RE: [PATCH] Enable device and console for ARM (II).

Another quick look at the source shows a couple of things.
++ every supported architecture does the malloc of syscalls_tbl. ++ console_setfile() currently requires it. ++ boot_command.c currently requires it. -- I'll retract the bit about console_init_r needing it, as I see that there is an alternative....and I wasn't using the syscall version anyway.
Do you still feel its allocation should be coded around? I quickly re-submit a patch with the VFD movement removed. If needed I can attempt to clean up the console_setfile and place in boot_command.c which currently needs it...but I defiantly am not in a position to test all effected ports.
...you are amazingly responsive for someone seven hours ahead...
Best Regards,
Richard W.
-----Original Message----- From: Woodruff, Richard Sent: Thursday, June 19, 2003 6:04 PM To: 'Wolfgang Denk' Cc: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] RE: [PATCH] Enable device and console for ARM (II).
Wolfgang,
The syscalls table allocation _IS_ Necessary to make the devices code, especially the console to work. In console.c : console_setfile() looks up the proper function pointers by using the syscalls table, console_init_r needs it also. You know the table is all of 11 longs. Rewriting the code to work differently would likely take up more space then using the table....And syscalls will show up.
As far as the VFD goes. I have no problem undoing the move. I am nearly positive that its move would have any effect. My rational was it should be in the devices init, so putting it close was the next best thing to doing it correctly.
Regards,
Richard W.
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Thursday, June 19, 2003 5:39 PM To: Woodruff, Richard Cc: u-boot-users@lists.sourceforge.net Subject: Re: [PATCH] Enable device and console for ARM (II).
In message FD2AC9A020DDD51194710008C7089B20053D4C81@dlee17.itg.ti.com you wrote:
Here is an updated patch against u-boot.0.3.0 with console_init_f defined. I added the call into what appears to be the
proper place,
into the init_sequence[], just like the PPC code does.
Sorry, but I reject this patch for the same reasons I just rejected the earlier version of this patch.
Again: the code is OK, and I want to include it, but you do a few things (VFD, syscalls) which you should leave as is.
Please resubmit.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems,
Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email:
wd@denx.de
Every little picofarad has a nanohenry all its own. -
Don Vonada
This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

In message FD2AC9A020DDD51194710008C7089B20053D4C98@dlee17.itg.ti.com you wrote:
Another quick look at the source shows a couple of things.
++ every supported architecture does the malloc of syscalls_tbl. ++ console_setfile() currently requires it. ++ boot_command.c currently requires it. -- I'll retract the bit about console_init_r needing it, as I see that there is an alternative....and I wasn't using the syscall version anyway.
OK, I give up. It seems this is buried too deep to be cleaned up right now.
Do you still feel its allocation should be coded around? I quickly re-submit a patch with the VFD movement removed. If needed I can attempt to clean up the console_setfile and place in boot_command.c which currently needs it...but I defiantly am not in a position to test all effected ports.
No, please make it work as is. The syscall cleanup will be another issue, some time later.
...you are amazingly responsive for someone seven hours ahead...
Ummm... ahead? No, I feel I must be weeks behind ... ;-)
Best regards,
Wolfgang Denk
participants (2)
-
Wolfgang Denk
-
Woodruff, Richard