[PATCH 2/3] mtd: maps: remove uclinux map driver

Greg Ungerer gerg at linux-m68k.org
Thu Jun 25 15:15:42 PDT 2026


Hi Arnd,

On 26/6/26 00:10, Arnd Bergmann wrote:
> On Thu, Jun 25, 2026, at 14:07, Greg Ungerer wrote:
>> On 26/5/26 20:32, Arnd Bergmann wrote:
>>
>> It is used on some ColdFire platforms, and was working all the way up
>> to being removed in the current merge window.
>>
>> The ColdFire platform startup code (arch/m68k/coldfire/head.S) has a
>> somewhat unusual setup that can copy an attached filesystem blob to
>> _bss_stop, and this is one of the places the uclinux.c map driver can
>> use as the filesystem memory address. From uclinux.c
>>
>>       static int __init uclinux_mtd_init(void)
>>       {
>>           struct mtd_info *mtd;
>>           struct map_info *mapp;
>>
>>           mapp = &uclinux_ram_map;
>>
>>           if (physaddr == -1)
>>                   mapp->phys = (resource_size_t)__bss_stop;
>>           else
>>                   mapp->phys = physaddr;
>>
>> No out of tree code is required. Most of the ColdFire defconfigs have
>> CONFIG_MTD_UCLINUX enabled, since it is commonly used.
> 
> I see, this is surprising from reading the source and
> git history, but I can see exactly how it got there.

The early, and probably more interesting history, predates git.
It has always "just worked" on ColdFire platforms, so it really hasn't
needed alot of change over the years for this use case.


> So this is not actually a device but rather a replacement
> for CONFIG_BLK_DEV_INITRD that does can work with CONFIG_BLOCK=y,
> right?

Yes, that is true. Typical use means adding "root=/dev/mtdblock0" to
kernel boot arguments.


>> Can we get this reverted?
> 
> Yes, of course. Miquel/Richard/Vignesh, should I send a revert or
> can you just apply one with Greg's explanation and my Ack?

Thanks
Greg




More information about the linux-mtd mailing list