RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200
Why is that so bad? It makes it possible to debug U-Boot with just loading the image into RAM using BDI2000.
Which is an unsupported mode of operation which works for a handfull of experts and causes confusion with many, many newbees.
How do these lines of code confuse a newbie more than any other code in the file?
But how would you debug U-Boot?
As I always do. Attach the BDI, burn to flash, start in GDB.
There are 53982 other hardware debuggers out there and only the minority (is there actually one besides the BDI?) support the burn to flash feature you rely on. So if you need to start U-Boot to flash U-Boot, you either do those few lines of code to skip the relocation or get/use another piece of actually redundant software to get the image on the flash. I don't know why the latter should save me time.
You can do this if you know exactly what you're doing,
Isn't this what is assumed here anyway?
Best regards, Lars Friedrich
-----Messaggio originale----- Da: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]Per conto di Friedrich, Lars Inviato: mercoledì, 24. novembre 2004 08:47 A: u-boot-users@lists.sourceforge.net Oggetto: RE: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200
Why is that so bad? It makes it possible to debug U-Boot with just loading the image into RAM using BDI2000.
Which is an unsupported mode of operation which works for a handfull of experts and causes confusion with many, many newbees.
How do these lines of code confuse a newbie more than any other code in the file?
You can do this if you know exactly what you're doing,
Isn't this what is assumed here anyway?
I fully agree with you !!!
Regards -Paolo Broggini
Best regards, Lars Friedrich
--
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Dear Lars,
in message AB4979EC12A5EB419810807434495A17283C1E@svex01001.wago.local you wrote:
Which is an unsupported mode of operation which works for a handfull of experts and causes confusion with many, many newbees.
How do these lines of code confuse a newbie more than any other code in the file?
It's not the lines of code, but the mode of operation. People tend to underestimate the complexity of the task and the impact of the required modifications.
As I always do. Attach the BDI, burn to flash, start in GDB.
There are 53982 other hardware debuggers out there and only the minority (is there actually one besides the BDI?) support the burn to flash feature you rely on. So if you need to start U-Boot
C'me on. You must be joking. Please name a few commercial debuggers which do not support flash programming. Maybe we should add a list of such broken devices to our wiki so people can avoid them?
Let me check:
* Abatron BDI2000: ok (of course) * Windriver visionICE II: ok * Lauterbach Trace32: ok * Macraigor Wiggler / Raven / usbDemon: ok * Agilent 3070 Series etc: ok
Even the free BDM4GDB project suports flash programming.
Please be specific: which BDM/JTAG debugger cannot program flash? I really would like to know to be able to warn our customers.
You can do this if you know exactly what you're doing,
Isn't this what is assumed here anyway?
Yes. People should think, machines should work ;-)
There are areas, where small errors have small consequences which are easy to spot. AQnd there are really nasty problems. If you look back at the archives you will see that this is one of these nasty problem domains. And it's a FAQ.
Best regards,
Wolfgang Denk
participants (3)
-
Friedrich, Lars -
Paolo Broggini -
Wolfgang Denk