Re: PowerPC progress
Hi Simon. > On Aug 3, 2020, at 11:01 AM, Simon Glass wrote: > > > Hi Tom, > > On Fri, 31 Jul 2020 at 12:54, Tom Rini wrote: >> >> On Fri, Jul 31, 2020 at 12:43:59PM -0600, Simon Glass wrote: >> >>> Hi Tom, >>> >>> I do see some progress with PowerPC migration but it seems to be very >>> behind. I notice that it is often PowerPC code that gets in the way or >>> refactoring and cleaning up. >>> >>> Could we get a progress update on this please? I cc'd the maintainers >>> that are mentioned in the code. I do worry at the effort it is taking >>> to keep all this old code in the tree. >> >> Which particular area are you worried about currently? I believe we've >> had another good sized removal of PowerPC platforms and everything >> that's left is what's wanted and being further migrated and updated. > > It's hard to be specific, but these come to mind: > > - Loads of CONFIG options still not in Kconfig > - asm/u-boot seems to include a huge array of headers > - code style not up-to-date - e.g. printf (xxx) instead of printf(xxx) > - lots of migration warnings I still have a few old boards, I’ll see what is still functional and jump in to assist. If we want to revive 82xx, as Wolfgang mentioned, I can probably do that as well. The list above is helpful to get started. Thanks. — Dan
Re: PowerPC progress
> On Aug 1, 2020, at 10:55 AM, Wolfgang Denk wrote: > > > Dear Tom, > > In message <20200731185425.GK6965@bill-the-cat> you wrote: >> >> Which particular area are you worried about currently? I believe we've >> had another good sized removal of PowerPC platforms and everything >> that's left is what's wanted and being further migrated and updated. > > Actually we're just discussing with a customer to bring MPC82xx back > into mainline (and maintain it for another 5...7 years …. I still have some development boards….. :) — Dan
Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors
On Jan 15, 2014, at 2:11 PM, Wolfgang Denk w...@denx.de wrote: ….. so we will keep it all, and just throw out the offending boards. Cool! :) I'll have to dig out some old boards and see if they still work. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Limit of kernel size
On Sep 15, 2012, at 4:40 PM, J.Hwan Kim wrote: Is there limitation of the kernel size which u-boot loads? No. My kernel is very big, because I included the ramdisk into the kernel. My kernel size is over 40MB. When I load the kernel through u-boot, the prcedure hangs in the boot step. The step is Uncompressing Linux done, booting the kernel Yeah, I don't know what architecture you are using or the format of your image, but I suspect the problem is with the wrapper or start up code of the image. There are lots of ways split/format such an image, I'd suggest asking on the architecture specific Linux mailing list. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On Dec 8, 2010, at 11:11 AM, Scott Wood wrote: Probably want to complain to the user if reg is invalid and not zero/missing. I think you guys are making this too complicated. There are many ways to pass stupid mistakes via a device tree, don't get carried away trying to single out this one for error checking where the user is likely to really know what they are doing. This isn't a required specification to get correct, without anything u-boot will provide the proper information. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
Hi Wolfgang. On Dec 8, 2010, at 1:38 PM, Wolfgang Denk wrote: If you want to make this switchable at runtime, then we should probably use an environment setting. I experimented with this, but could never determine the best way to cover all behavior. Do we have a variable that indicates don't update DT? If so, it means we have to place all values in the DT, when it's really nice for U-Boot to do some of that for us. In fact, we want U-Boot to update many things it discovers, just not the few we wish to actually (sometimes) define for ourselves. The other alternative (granted, I'm not as smart as I used to be :-)) was to have an environment variable that specified which node we didn't want updated by U-Boot. For now, that seems reasonable since there is only one, but is that the general approach we want in the future? It also presents the challenge of having to update both environment and the provided DT. I just wanted to make these points, as I did try some alternatives but never found anything acceptable. By looking at key values in the DT, at least it was confined to one place. This feature is needed, so I propose we let it exist in the form we have found useful and let it evolve over time as others gain some experience. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On Dec 8, 2010, at 2:34 PM, Wolfgang Denk wrote: You can please all the people some of the time and some of the people all of the time but you can't please all the people all of the time. Yes, I'm sometimes pleased :-) My current thinking is to introduce something like . Well, that is pretty cool. dt_skip=memory,mac-address Do we have to write a parser now, or is there something that currently exists to help out? :-) Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/3] FDT: Add fixup support of multiple banks of memory
On Aug 10, 2010, at 12:39 PM, Grant Likely wrote: . At the moment, I think firmware should be restricted to only touching the /chosen node, the /memory node, I don't even want it updating these, except maybe for the processor clock speeds. I'm trying to use device trees as a mechanism for providing resource allocation information in a partitioned, multi-core system. In this case, I don't want the boot firmware making updates to the device tree. I understand in many cases it's quite convenient to have the boot firmware update the device tree prior to invoking the OS, but this is one time when it's not appreciated. I'm currently experimenting with two models, one using environment variables and another using some kind of device tree tagging (i.e. don't update value if it's not equal to some unique key). Neither method has proven to be better in all cases. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/3] FDT: Add fixup support of multiple banks of memory
On Aug 10, 2010, at 1:26 PM, Grant Likely wrote: Hi Dan! I'm glad you're reading as you're one of the use-cases I was thinking about. :-) Hi Grant. Yeah, it's me, the special case :-) ... but I gather from your comment that even that causes problems in your use-case. The /chosen hasn't really caused any trouble. (or is it the /memory node that is the issue?) Yep, /memory is the big problem. Can you give a concrete example so I understand the issue? The /memory node update was implemented to match the historical behaviour of u-boot setting the memory size in the board_info structure, but perhaps that shouldn't be unconditional. I use the /memory to define the start/size of the various partitions, which of course only one starts at the base address and none of them represent the entire memory space. Updating this as we do today is bad, but then I can think of other complex ways it could be useful. :-) Like... specify a percentage in the node property and have the firmware update base/size according to previous device tree requests. But, not today. A little off topic, but since we tend to discuss device trees here. I think Hollis has discussed our use of an enabled property, which has become useful. It's becoming evident that it's valuable to define the entire device tree, but then have a property for the device that specified whether it's enabled for use in a particular partition. Today, we take a device tree, make copies for each partition, and modify enabled accordingly. I guess it could be extended to include partition information in the property, and we could then perhaps use a single tree for all partitions. The kernel or device drivers then test this to determine if this instance should be using this device. Anyway, just information I'd thought I'd pass along that is still brewing. I don't know if this has any value to boot firmware, maybe yet another way to control device tree updates. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] Early serial debug console
On Aug 15, 2008, at 2:16 PM, Peter Tyser wrote: Does anyone have suggestions/comments? Any chance this feature could make it into mainline U-Boot? Are going to take on the challenge of making this work with processors that use CPM/QE devices for serial ports? :-) Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
