[U-Boot-Users] How to compile uBoot in ADS
Hello there,
One of my friend need to compile uBoot in ADS IDE for OMAP platform, Does anyone have done semilar job or give me some hint about it? Thanks a lot!
Best Regards, Mark
In message 3578894547A2D511A82500D0B7F0FF9C0CF198BB@zch01exm02.sps.mot.com you wrote:
One of my friend need to compile uBoot in ADS IDE for OMAP platform, Does anyone have done semilar job or give me some hint about it?
It's a two stage job. In the first stage, chose a known to be working environment. For example, install Linux and the ELDK.
Seriously - why going through all the trouble to get some exotic toolchain working if you can do the job in half an hour with existing free tools?
Best regards,
Wolfgang Denk
Hello list,
I try to use an external UART with an ARM9 of NetSilicon. The driver for Linux works fine. In u-boot I thougt about using the NS16550 driver and it workes fine, too. I see the output and can use the console to make changes to the u-boot commands. Now my problem: Using an u-boot with the NS16550 makes linux not booting any more. The last message I get is "Starting kernel ...". It is not possible to ping the target any more. Using an u-boot without the NS16550 driver works. I don't see the u-boot output but linux starts normal.
Any ideas what's going wrong?
regards,
-- Jonas
Evening again...
Is there any reason that most of the board specific PCMCIA code resides in "common/cmd_pcmcia.c" ?
rick
In message <r02010400-1037-702545FA582F11D99E9A00039387ACB6@[10.0.1.1]> you wrote:
Is there any reason that most of the board specific PCMCIA code resides in "common/cmd_pcmcia.c" ?
Yes, there is: that was what I found in the Linux kernel when I started working on this, and from then on the file has just grown. So it's historical reasons once again.
Best regards,
Wolfgang Denk
And one for tthe night (o;
I see there exists CFG_FPGA_ALTERA and some altera fpga code in latest u-boot...obvioulsy no existing board in the cvs is using it...
So nobody using it at all or has there been no feedback to the cvs?
rick
In message <r02010400-1037-702545FA582F11D99E9A00039387ACB6@[10.0.1.1]> you wrote:
Is there any reason that most of the board specific PCMCIA code resides in "common/cmd_pcmcia.c" ?
Yes, there is: that was what I found in the Linux kernel when I started working on this, and from then on the file has just grown. So it's historical reasons once again.
So you wouldn't mind if I place the board specific code into "board/Opus103/pcmcia.c" ? (o;
Just don't like messing around with things in "common/" (o;
best regards rick
In message <r02010400-1037-C5A9F124585411D983EB00039387ACB6@[10.0.1.1]> you wrote:
So you wouldn't mind if I place the board specific code into "board/Opus103/pcmcia.c" ? (o;
Not really. I also wouldn't object against a patch that cleans this up for all boards ;-)
Just don't like messing around with things in "common/" (o;
A laudable attitude.
Best regards,
Wolfgang Denk
In message 41D03CB0.2020306@fsforth.de you wrote:
Using an u-boot with the NS16550 makes linux not booting any more. The last message I get is "Starting kernel ...". It is not possible to ping the target any more. Using an u-boot without the NS16550 driver works. I don't see the u-boot output but linux starts normal.
Any ideas what's going wrong?
You have a problem in your Linux kernel. The Linux drivers must not make any assumptions about any initialization done or not done by any boot loader. Fix your Linux driver.
See also the related FAQ at http://www.denx.de/twiki/bin/view/DULG/EthernetDoesNotWorkInLinux
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote：
Jonas Dietsche maillist@fsforth.de wrote:
Using an u-boot with the NS16550 makes linux not booting any more. The last message I get is "Starting kernel ...". It is
It seems that NS16550 driver in kernel wasn't enabled or work right.
The Linux drivers must not make any assumptions about any initialization done or not done by any boot loader. Fix your Linux driver.
But one exception for serial console driver. I found there wasn't enable control of UART receiver in 8xx kerenl serial console driver uart.c. Maybe this driver make a assumption that boot loader does this job? At least I ported the driver work right on my 8xx custom board without any change in it:-)
Also, sometimes we could initialize some status in U-Boot for ready and then change it in kerenl to finish some special work. I once made the LCD backlight in boot process of my target like PC did to aviod seeing the LCD screen flickering. First enable and then shut down in u-boot, open it later in LCD kernel driver:-)
IMHO, if one person did u-boot and kernel port both, he would have the chance to consider the harmony between U-Boot and Kernel. So some initialization like receiver enable in kernel driver could be omitted. Is this an informal idea?
Thanks for your nice time,
===== Best regards,
Sam
_________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1...
In message 20041228013654.47236.qmail@web15602.mail.cnb.yahoo.com you wrote:
The Linux drivers must not make any assumptions about any initialization done or not done by any boot loader. Fix your Linux driver.
But one exception for serial console driver. I found there wasn't enable control of UART receiver in 8xx kerenl serial console driver uart.c. Maybe this driver make a assumption that boot loader does this job? At
It should not. But there are bugs and bugs and ...
Also, sometimes we could initialize some status in U-Boot for ready and then change it in kerenl to finish some special work. I once made the LCD backlight in boot process of my target like PC did to aviod seeing the LCD screen flickering. First enable and then shut down in u-boot, open it later in LCD kernel driver:-)
Of course there are many situations where an (intentional) deviation from these rules may be necessary - loading a splash screen in U-Boot and passing a pre-initialized framebuffer to Linux is one of these areas.
IMHO, if one person did u-boot and kernel port both, he would have the chance to consider the harmony between U-Boot and Kernel. So some initialization like receiver enable in kernel driver could be omitted. Is this an informal idea?
Actually it is a bad idea if the kernel makes assumptions about which boot loader is used, or which initializations the boot loader performes. Yes, we all like U-Boot more than every other boot oader, but why knows what sort of boot loader the next guy booting your kernel wants or has to use? Don't make life more difficult for him than absolutely necessary.
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote：
But one exception for serial console driver. I found there wasn't enable control of UART receiver in 8xx kerenl serial console driver uart.c. Maybe this driver make a assumption that boot loader does this job?
It should not. But there are bugs and bugs and ...
So I know what the driver could be...
IMHO, if one person did u-boot and kernel port both, he would have the chance to consider the harmony between U-Boot and Kernel. So some initialization like receiver enable in kernel driver could be omitted. Is this an informal idea?
Actually it is a bad idea if the kernel makes assumptions about which boot loader is used, or which initializations the boot loader performes. Yes, we all like U-Boot more than every other boot oader, but why knows what sort of boot loader the next guy booting your kernel wants or has to use? Don't make life more difficult for him than absolutely necessary.
Hi, Wolfgang. I appreciate your reply in the view of kernel rather than u-boot. Well, sounds a little bit late to answer your help but after a deep consideration:-)
Thanks very much and Happy New Year!
===== Best regards,
Sam
_________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1...
Wolfgang Denk wrote on 12/27/04 21:10:
You have a problem in your Linux kernel. The Linux drivers must not make any assumptions about any initialization done or not done by any boot loader. Fix your Linux driver.
I just tried to take out the serial driver of the kernel. Still the same problem, last message "Starting kernel..." (ok, have to be the last one, because I have no console...). But I am still not able to ping the target. Using an u-boot without the serial driver and linux boots. Is it really a misconfigured linux driver, or should I focus on my u-boot driver?
Regards,
-- Jonas
participants (5)
-
Jonas Dietsche -
richard＠uclinux.net -
Sam Song -
Wolfgang Denk -
Yu JunMiao-r61929