SD card emulator

[mac.6]

This smells like continuous integration server (jenkins/bamboo) with automated builds...

[rob77]

There are no pre-verified images, this is during development hence the testing. How this process works: a new build of the firmware is generated after making changes, now we need to see if it works and the performance.

1) Write new firmware to SD card
2) Attempt to boot device (check bootloader)
3) Attempt to boot kernel (check kernel)
4) If successful boot, run series of tests/benchmarks and record results (check drivers, application, etc)

i did a boatload of embedded stuff and even custom linux distros (mainly for x86 based network gear) and i can tell you you're not doing it the most efficient way.

you have to have a "soft" test-bed for testing builds and once it passes all the regression tests in the soft test-bed then you can go for hardware.... a virtualized test enviroment will boot and run the tests in seconds, compared to minutes when testing on hardware (flash SD, boot HW) .. you can use QEMU for arm on x86 host, and for x86 on x86 host you can use any virtualization software.

in general you always have to test in software first, otherwise you'll waste you time... for example back in time when i was writing a network driver kernel module - i was using UML (user mode linux) for the early stage of development.. UML was running an another instance of linux kernel as process on the host linux OS and provided the ideal soft test-bed.. once the HW independent part was OK and stable i moved to the hardware part on real HW. doing that all on hardware from beginning, i would be still doing it (that was approx 10-11 years ago)

[vpeter]

So they and they are doing it also wrong?  I really doubt that.

[rob77]

So they and they are doing it also wrong?  I really doubt that.

you should distinguish between different use cases.
1. testing software during development - this is much faster in a virtualized environment (soft test-bed)
2. testing boards during manufacturing - this can be done with a bunch of SD cards

of course if you have a hardware without a possibility of virtualization then you have to go for testing on hardware where such a SD card switch or even SD emulator has it's benefits.

and as always - there are many ways to achieve the same goal.

so feel free to doubt anything you wish... but i've been there... just sharing my experience

[encore2097]

Thanks for all the answers. I ended up with a nifty solution.

This smells like continuous integration server (jenkins/bamboo) with automated builds...

Spot on. Though entirely custom, fast, feature-ful and the next step in how hardware and software is built and tested.

So they and they are doing it also wrong?  I really doubt that.

The folks who worked on this are amazing and great inspiration! I've spoken to them deeply about this problem and while this was the a fast solution at the time, there is much room for improvement.

So they and they are doing it also wrong?  I really doubt that.

you should distinguish between different use cases.
1. testing software during development - this is much faster in a virtualized environment (soft test-bed)
2. testing boards during manufacturing - this can be done with a bunch of SD cards

of course if you have a hardware without a possibility of virtualization then you have to go for testing on hardware where such a SD card switch or even SD emulator has it's benefits.

and as always - there are many ways to achieve the same goal.

so feel free to doubt anything you wish... but i've been there... just sharing my experience

Its quite amazing how many sharp people tell someone they are wrong or doing things "inefficiently" without even understanding the problem. You have made so many assumptions without even attempting to understand my use case.

I'm not using x86, but custom RISC hardware. I've already tested in software and trying to emulate in virtualization would be 100x slower than hardware and require FPGAs. e.g. How do you "test" HDMI/LVDS bring up or hardware accelerated network features of your NIC in software?

Whats the difference between theory and practice? In theory, there is no difference. If you are not testing on actual hardware, you are shipping your customers lots of bugs.

[mikeselectricstuff]

Its quite amazing how many sharp people tell someone they are wrong or doing things "inefficiently" without even understanding the problem.

But it can equally be the case that you are utterly convinced you have thought through all the possibilities, but someone else comes at it from a different angle to solve a problem in a different way
you'd not considered

You have made so many assumptions without even attempting to understand my use case.

Maybe if you'd given more details of your requirements, you'd have got more appropriate suggestions.

[Rasz]

How do you "test" HDMI/LVDS bring up or hardware accelerated network features of your NIC in software?

what does that have to do with testing bootstrapping?
hardware emulation of boot medium gives you precisely ONE advantage - ability to test bootloader. With bootloader tested and working everything else is just network/serial connection transfer away.

You dont need to swap(virtually) SD cards to test hdmi. You sound very young and enthusiastic, and quick to dismiss old farts who have been there and done that several times over.

[3db]

How do you "test" HDMI/LVDS bring up or hardware accelerated network features of your NIC in software?

what does that have to do with testing bootstrapping?
hardware emulation of boot medium gives you precisely ONE advantage - ability to test bootloader. With bootloader tested and working everything else is just network/serial connection transfer away.

You dont need to swap(virtually) SD cards to test hdmi. You sound very young and enthusiastic, and quick to dismiss old farts who have been there and done that several times over.

Are you an old fart too ?   
I'm an old fart have you graduated to grumpy old fart yet ? 

[il__ya]

Thanks for all the answers. I ended up with a nifty solution.

encore2097, sorry for bumping this 3 years old thread, but may I ask what the eventual solution was? I am facing a similar problem at the moment, and would be interested to know how you solved it.

[encore2097]

Thanks for all the answers. I ended up with a nifty solution.

encore2097, sorry for bumping this 3 years old thread, but may I ask what the eventual solution was? I am facing a similar problem at the moment, and would be interested to know how you solved it.

Its unfortunate that I missed this.

Here's what I came up with: https://hackaday.io/project/19783-sd-card-emulation

[coromonadalix]

i recently saw an sd card emulator on Ali for Dwin Hmi displays

https://www.aliexpress.com/item/32917802827.html?spm=a2g0o.cart.0.0.2c523c00ps3UBV&mp=1

10,80$ usd

and this one too

https://www.aliexpress.com/item/32830983955.html?spm=a2g0o.cart.0.0.2c523c00ps3UBV&mp=1

9.90$ usd ??

[donotdespisethesnake]

Those don't emulate an SD card, they are adapters which provide a comms channel from SPI to the USB. The SD card socket is just a way to get to the SPI signals.

[aldolo]

Any news on this topic? So far I'm considering using 2 real sd card, one on-line and one off-line. the off-line one could be written to using an arduino while the on-line one is used by the final device. then it is easy to swap the 2 with few gates.

[SimonR]

Somewhere around 2007/8 I did exactly this more or less.
My company developed an ASIC that had an SDIO interface which is effectively an SD card with a peripheral on it instead of flash memory.

During development we used an off the shelf SDIO chip until the ASIC (Test FPGA) was ready. Our application was communications device that transferred a lot of data. You could easily have used the chip to implement a memory card, which we were also considering at one point for test purposes.

The chip in question was from a company called Arasan and just a demonstration chip for their IP which I think we used. Its not available any more but Arasan seem to be going still

https://www.arasan.com/products/

Alternatively while I was searching for the Arasan chip I also found this from Lattice

http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/EurekaCores/EP560SDSDIOMMCSlaveController

This looks like it might be what everyone is looking for.

Just a suggestion

[ethaniel]

Sorry for bumping up an old thread. I'm willing to set a $2K bounty on this if anyone is interested in exploring the idea.

I'm trying to find a way how to capture data that's being written to a microsd card and receive it live on linux.

I've got a GoPro MAX which can record 360 degrees video. It doesn't have an HDMI output.
I want to extract the h264/h265 video data as it's being written into files on the "virtual" microsd card.

I assume there is alot of wizardry involved - letting the gopro know that this it's a working sd card with an actual filesystem and free space available. Perhaps somehow patch it through to a virtual block device in linux? There is a lot of data transfer involved (100+ megabytes per second).

My goal is to use feed the raw h264 into a streaming program, so I could use the GoPro as a 24/7 live camera.

Anyways, the bounty is $2K. Looking forward to hearing back from you.